Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory,sci.logic
Subject: Re: My reviewers think that halt deciders must report on the behavior
 of their caller
Date: Wed, 16 Jul 2025 10:05:48 +0200
Organization: A noiseless patient Spider
Lines: 141
Message-ID: <1057mgt$21svn$3@dont-email.me>
References: <101nq32$99vd$1@dont-email.me>
 <960c2417e6f691b2b12703506c207990df5b39ab@i2pn2.org>
 <104el09$2dpog$1@dont-email.me>
 <1ca786773f9ff02718c66e082bbc4182b36732ab@i2pn2.org>
 <104fduv$2n8gq$2@dont-email.me>
 <4cb5d16be8d1e6549823f35081050e7dad462da2@i2pn2.org>
 <104gi8j$2uc68$2@dont-email.me>
 <152859a4a4ef31aa45580e873eb6970c34b97ef9@i2pn2.org>
 <104hmb5$35gkb$1@dont-email.me>
 <f12be9e3474cf08b01ae1a4381f77205bbac1da3@i2pn2.org>
 <104i15g$36mma$2@dont-email.me>
 <c0cf1db3b26b15b6b2df8a22e9f415c10aee59a7@i2pn2.org>
 <104jcqn$3jrpl$10@dont-email.me> <104lb03$13ioh$2@dont-email.me>
 <104lp8o$7l4q$7@dont-email.me> <104o662$18h8g$1@dont-email.me>
 <104oj2v$t0u4$7@dont-email.me> <104qjcg$1c0m7$1@dont-email.me>
 <104ruag$1ml84$3@dont-email.me> <104t5nk$1frch$2@dont-email.me>
 <104tuh6$264oq$9@dont-email.me> <104vij5$1jfin$2@dont-email.me>
 <1050juk$2qkok$6@dont-email.me> <1052i2m$1pbs1$1@dont-email.me>
 <10530ga$3dptv$4@dont-email.me> <10559er$1tk4j$3@dont-email.me>
 <1055hn6$2t13$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 16 Jul 2025 08:05:50 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="ae2ccd3471d9d8f0722027260a4a6d29";
	logging-data="2159607"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+WDxJHQrI3iCnT07/fjAZF"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:uLFv9Sn7uYeL9etbDRh2O7JTMMQ=
In-Reply-To: <1055hn6$2t13$1@dont-email.me>
Content-Language: nl, en-GB

Op 15.jul.2025 om 14:31 schreef olcott:
> On 7/15/2025 5:10 AM, Fred. Zwarts wrote:
>> Op 14.jul.2025 om 15:25 schreef olcott:
>>> On 7/14/2025 4:19 AM, Fred. Zwarts wrote:
>>>> Op 13.jul.2025 om 17:38 schreef olcott:
>>>>> On 7/13/2025 1:09 AM, Fred. Zwarts wrote:
>>>>>> Op 12.jul.2025 om 17:21 schreef olcott:
>>>>>>> On 7/12/2025 3:17 AM, Fred. Zwarts wrote:
>>>>>>>> Op 11.jul.2025 om 23:05 schreef olcott:
>>>>>>>>> On 7/11/2025 3:52 AM, Fred. Zwarts wrote:
>>>>>>>>>> Op 10.jul.2025 om 16:35 schreef olcott:
>>>>>>>>>>> On 7/10/2025 5:54 AM, Fred. Zwarts wrote:
>>>>>>>>>>>> Op 09.jul.2025 om 15:02 schreef olcott:>
>>>>>>>>>>>>> All Turing machine deciders only compute the mapping
>>>>>>>>>>>>> from their actual inputs. This entails that they never
>>>>>>>>>>>>> compute any mapping from non-inputs.
>>>>>>>>>>>>
>>>>>>>>>>>> At least one thing you understand.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *From the bottom of page 319 has been adapted to this*
>>>>>>>>>>> https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>>>>>>>>>>>
>>>>>>>>>>> *The Linz proof does not understand this*
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
>>>>>>>>>>>    *if Ĥ applied to ⟨Ĥ⟩ halts, and*
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>    *if Ĥ applied to ⟨Ĥ⟩ does not halt*
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> The evidence is that the input includes the code to abort 
>>>>>>>>>>>>>> and halt,
>>>>>>>>>>>>>
>>>>>>>>>>>>> abort and stop running
>>>>>>>>>>>>> *IS NOT THE SAME THING AS*
>>>>>>>>>>>>> abort and halt
>>>>>>>>>>>>
>>>>>>>>>>>> Another claim without evidence.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> *It is common knowledge in the theory of computation*
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Another claim without evidence.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Your lack of knowledge of computer science is not a rebuttal*
>>>>>>>>>
>>>>>>>>> Look at the definition of a Turing Machine (e.g., the one 
>>>>>>>>> here). The machine has states. Each state can be final or non- 
>>>>>>>>> final. If the machine's state is non-final, in the next step 
>>>>>>>>> the machine "does" something, namely, it can write something on 
>>>>>>>>> the tape, move its head, and/or change its state to a different 
>>>>>>>>> state. This is how the machine makes a progress.
>>>>>>>>
>>>>>>>> So, aborting the simulation when the machine has not yet reached 
>>>>>>>> its final state, is a violation of the Turing Machine.
>>>>>>>>
>>>>>>>
>>>>>>> void DDD()
>>>>>>> {
>>>>>>>    HHH(DDD);
>>>>>>>    return;
>>>>>>> }
>>>>>>>
>>>>>>> So you don't understand that DDD simulated by
>>>>>>> pure simulator HHH keeps repeating its first
>>>>>>> line forever?
>>>>>>
>>>>>> Irrelevant, because that is not what HHH does.
>>>>>
>>>>> void DDD()
>>>>> {
>>>>>    HHH(DDD);
>>>>>    return;
>>>>> }
>>>>>
>>>>> I stipulated this HHH <is> a pure simulator temporarily
>>>>> overriding and superseding everything else that I ever
>>>>> said about HHH.
>>>>
>>>> You can stipulate that, but is irrelevant for the HHH you published 
>>>> in Halt7.c. *That* HHH is not a pure simulator. The fact that a pure 
>>>> simulator fails is no proof for the correctness of the non-pure 
>>>> simulator.
>>>> Dreaming of other simulators with other behaviour does not change 
>>>> the factual behaviour of the HHH we are discussing.
>>>>
>>>
>>> void RRR()
>>> {
>>>    SSS(RRR);
>>>    return;
>>> }
>>>
>>> When RRR is simulated by pure simulator SSS
>>> RRR simulated by SSS never reaches its own
>>> "return" statement.
>>
>> You have been corrected on this many times, but you seem unable to 
>> understand it.
>> We are discussing a non-pure simulator, so the behaviour of a pure 
>> simulator is irrelevant.
>>
>>>
>>> When we adapt SSS so that it only simulates
>>> N instructions of RRR then no RRR ever reaches
>>> its own "return" statement.
> 
>> Now there is a final halt state, but SSS is unable to reach it. This 
>> illustrates that simulation is not the right tool for this input to 
>> analyse the behaviour, because it cannot see the full specification. 
>> Other tools are needed, but each tool will fail for some inputs.
> 
> _DDD()
> [00002192] 55             push ebp
> [00002193] 8bec           mov ebp,esp
> [00002195] 6892210000     push 00002192  // push DDD
> [0000219a] e833f4ffff     call 000015d2  // call HHH
> [0000219f] 83c404         add esp,+04
> [000021a2] 5d             pop ebp
> [000021a3] c3             ret
> Size in bytes:(0018) [000021a3]
> 
> So when the actual behavior of the actual x86 code
> disagrees with you you disagree with the x86 language.
> 

And since it does not disagree with me, but with the premature abort of 
your HHH, the semantics of the x86 language are on my side.
The actual X86 code specifies a program that reaches its final halt 
state, as proven by other simulators and direct execution.
When HHH returns with a value of 0 (as you tell us that it does) the 
correct simulation will continue at 0000219f and then reach the final 
halt state.
If HHH fails to reproduce that behaviour, specified by exactly the same 
code, then the simulation by HHH is in error, because it cannot see the 
full specification of the input.