Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: How the requirements that Professor Sipser agreed to are exactly
 met
Date: Tue, 13 May 2025 07:46:55 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <b7e048a9a61fd5ebf8c68c6506d81fc15f3a07b5@i2pn2.org>
References: <vvm948$34h6g$2@dont-email.me> <87v7q5n3sc.fsf@bsb.me.uk>
 <vvtf7n$17c1i$5@dont-email.me> <87plgdmldp.fsf@bsb.me.uk>
 <vvuala$1hi3q$1@dont-email.me> <vvubuk$1deu5$4@dont-email.me>
 <c92c09994a27681313b2d212ae8b4bd3328fe3a1@i2pn2.org>
 <vvuii6$1j6s0$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 13 May 2025 11:47:30 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="172461"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vvuii6$1j6s0$2@dont-email.me>
Content-Language: en-US

On 5/13/25 12:41 AM, olcott wrote:
> On 5/12/2025 11:11 PM, Richard Damon wrote:
>> On 5/12/25 10:48 PM, olcott wrote:
>>> On 5/12/2025 9:26 PM, Richard Heathfield wrote:
>>>> On 13/05/2025 00:58, Ben Bacarisse wrote:
>>>>> On the other hand, you are spending a lot of time arguing about his
>>>>> knowledge and use of C.  Yes, it's awful.  He knows very little C and
>>>>> the code is crap, but that/is/  a straw man -- it's the simplest 
>>>>> part of
>>>>> his argument to fix.
>>>>
>>>> Although it was an attempt to motivate him to improve the code, it 
>>>> has become blindingly obvious that he's not interested, which is 
>>>> precisely why I am going to stop bothering.
>>>>
>>>
>>> Do you really think that nit picky details
>>> can refute the gist of what I am saying
>>> that needs none of these details?
>>
>> Since you have yet to show that ANY of your claims are actually making 
>> the point you want, you should be looking for small gains.
>>
>>>
>>> int DD()
>>>   {
>>>    int Halt_Status = HHH(DD);
>>>    if (Halt_Status)
>>>      HERE: goto HERE;
>>>    return Halt_Status;
>>>   }
>>
>> Which isn't a program that can be simulated until you pair it with the 
>> HHH that it calls, and that will be a different program input for each 
>> HHH that it pairs with.
>>
>>>
>>> DD correctly simulated by any pure simulator
>>> named HHH cannot possibly terminate thus proving
>>> that this criteria has been met:
>>
>> So, you can prove that for HHH being a pure simulator, it won't reach 
>> the end, but only after creating an input that calls that HHH, and 
>> thus can't be decided on by any other HHH that you can think of.
>>
>>>
>>> <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>      If simulating halt decider H correctly simulates its
>>>      input D until H correctly determines that its simulated D
>>>      would never stop running unless aborted then
>>>
>>>      H can abort its simulation of D and correctly report that D
>>>      specifies a non-halting sequence of configurations.
>>>   </MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
>>>
>>
>> Yes, *THAT* HHH is allowed to abort, but only because it doesn't.
> 
> This only has one meaning.
> *its simulated D would never stop running unless aborted*
> 

Right, but not restricted to the partial simulation that H does, it meas 
the actual CORRECT AND COMPLETE simulation of D would never stop running.

By your definution, a decider can just stop at any point and say that is 
all I can do, this isn't halting.

The problem is your system starts by breaking the rules, as you D isn't 
a program as required, since you exclude the H it calls, allowing you to 
try to get away with changing it, but all that does is show you have 
always been a liar.