Deutsch   English   Français   Italiano  
<vqtn29$330k5$2@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Every sufficiently competent C programmer knows --- posthumous
 reviewers
Date: Wed, 12 Mar 2025 23:31:05 -0500
Organization: A noiseless patient Spider
Lines: 169
Message-ID: <vqtn29$330k5$2@dont-email.me>
References: <vqntaq$1jut5$1@dont-email.me> <vqp388$1tvqa$1@dont-email.me>
 <vqpdv9$202b2$2@dont-email.me> <vqperb$20c9k$2@dont-email.me>
 <E6mcnWv3nMa66036nZ2dnZfqnPWdnZ2d@brightview.co.uk>
 <vqpv2u$23vhr$1@dont-email.me>
 <Ny-dnRlMHcVpA036nZ2dnZfqnPqdnZ2d@brightview.co.uk>
 <vqrjrn$2h4l2$1@dont-email.me>
 <nESdnUfJxdhoTkz6nZ2dnZfqnPSdnZ2d@brightview.co.uk>
 <vqsl7c$2ok91$1@dont-email.me>
 <f7b6995ae3e79db00fa5070d9be8126b7ea5ae78@i2pn2.org>
 <vqt99l$2spcd$5@dont-email.me>
 <19f984112c68c4c88d3cbb2f568afc8b59fe2605@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 13 Mar 2025 05:31:06 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c857a159987cd29a4265e3ac68f94ca5";
	logging-data="3244677"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/vWTWW4tigcR91GMERf2em"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Z68XsOD9PW+4ErsXYVLIcXNE/ic=
In-Reply-To: <19f984112c68c4c88d3cbb2f568afc8b59fe2605@i2pn2.org>
Content-Language: en-US
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250312-2, 3/12/2025), Outbound message

On 3/12/2025 10:56 PM, Richard Damon wrote:
> On 3/12/25 8:36 PM, olcott wrote:
>> On 3/12/2025 5:47 PM, Richard Damon wrote:
>>> On 3/12/25 2:53 PM, olcott wrote:
>>>> On 3/12/2025 1:35 PM, Mike Terry wrote:
>>>>> On 12/03/2025 09:24, Fred. Zwarts wrote:
>>>>>> Op 11.mrt.2025 om 21:37 schreef Mike Terry:
>>>>>>> On 11/03/2025 18:23, Richard Heathfield wrote:
>>>>>>>> On 11/03/2025 17:42, Mike Terry wrote:
>>>>>>>>> Finally, if you really want to see the actual HHH code, its in 
>>>>>>>>> the halt7.c file (along with DDD) that PO provides links to 
>>>>>>>>> from time to time.  However it's not very illuminating due to 
>>>>>>>>> bugs/ design errors/ misunderstandings which only serve to 
>>>>>>>>> obfuscate PO's errors in thinking.
>>>>>>>>
>>>>>>>> [I've now seen the code. Oh deary deary me.]
>>>>>>>
>>>>>>> :)
>>>>>>>
>>>>>>>>
>>>>>>>> Thank you for a spirited attempt to be cogent - or at least as 
>>>>>>>> cogent as it is possible to be in the circumstances!
>>>>>>>>
>>>>>>>> I think PO's first step must be to demonstrate that HHH() 
>>>>>>>> correctly diagnoses some easy functions, such as these:
>>>>>>>
>>>>>>> Not really necessary - PO is not trying or claiming to have a 
>>>>>>> (full) halt decider.
>>>>>>>
>>>>>>> Originally his claim was that he had a program which worked for 
>>>>>>> the counter-example TM used in the common (e.g. Linz book) proof. 
>>>>>>> Such a program is impossible, as Linz and others prove, so having 
>>>>>>> a program H and its corresponding "counter-example" D, such that 
>>>>>>> H correctly decides D, would certainly show that the Linz proof 
>>>>>>> is wrong.  His claim was always that he had "refuted the HP 
>>>>>>> proof", or sometimes that he had refuted the HP theorem itself 
>>>>>>> although he's been told dozens of times that there are many 
>>>>>>> alternative proofs for the result.
>>>>>>>
>>>>>>> [As it turned out, PO's D(D) halted when run under his x86utm 
>>>>>>> environment, while H(D,D) which is required to return the halting 
>>>>>>> status of computation D(D) returned 0 (=non-halting).  That is 
>>>>>>> exactly what the Linz proofs claim!]
>>>>>>>
>>>>>>> Anyhow, his decider only /has/ to correctly decide the one input, 
>>>>>>> which is the D constructed from H by the usual method (basically 
>>>>>>> D calls H to see what H claims is the halting behaviour, then 
>>>>>>> does the opposite - I'm not sure if you're familiar with the 
>>>>>>> proof, but imagine you would be given your background).
>>>>>>>
>>>>>>> His decider H works (subject to design errors/bugs and so on) by 
>>>>>>> single- stepping a simulation of its input computation, and 
>>>>>>> monitoring for conditions that PO believes indicate non- 
>>>>>>> termination. He tests a couple of conditions, and when one of 
>>>>>>> those matches H aborts and returns non- halting. Alternatively if 
>>>>>>> the simulation halts normally, H returns halting.  The problem is 
>>>>>>> (at least) one of his non-halting-behaviour tests is invalid, 
>>>>>>> matching during the simulation of DDD, which is a halting 
>>>>>>> computation.
>>>>>>
>>>>>> It seems that he does not understand that the these conditions 
>>>>>> (that indicate non-termination behaviour), form exactly the 
>>>>>> halting problem.
>>>>>> PO claims that simulation is the solution, but he only shifts the 
>>>>>> problem of non-termination detection to the detection of these 
>>>>>> 'special conditions'.
>>>>>> When we realise that, we understand that a finite or infinite 
>>>>>> simulation is not very relevant. The discussion should address 
>>>>>> these conditions. But PO carefully avoids discussions about the 
>>>>>> detection of these conditions, although they are the heart of the 
>>>>>> problem.
>>>>>
>>>>> I completely agree.
>>>>>
>>>>> We could create a (partial) simulating halt decider (PSHD) that 
>>>>> works by simulating the steps of its input computation, and looking 
>>>>> for patterns in the resulting trace indicating halting or non- 
>>>>> halting behaviour.  If these patterns were /*sound*/, meaning that 
>>>>> matching guarantees the computation behaviour is indeed halting/ 
>>>>> non- halting as the test claims, then the PSHD could abort the 
>>>>> simulation and decide halting behaviour correctly on that basis.  
>>>>> [This much is obvious, and is basically what Sipser means in his 
>>>>> "agreement" statement that PO often quotes, although PO has his own 
>>>>> differing interpretation of what that means.]
>>>>>
>>>>
>>>> _DDD()
>>>> [00002172] 55         push ebp      ; housekeeping
>>>> [00002173] 8bec       mov  ebp,esp  ; housekeeping
>>>> [00002175] 6872210000 push 00002172 ; push DDD
>>>> [0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
>>>> [0000217f] 83c404     add  esp,+04
>>>> [00002182] 5d         pop  ebp
>>>> [00002183] c3         ret
>>>> Size in bytes:(0018) [00002183]
>>>>
>>>> When DDD is emulated by HHH according to the semantics
>>>> of the above x86 machine language then DDD cannot possibly
>>>> reach past its own machine address 0000217a.
>>>>
>>>> My posthumous reviewers will notice that my current
>>>> reviewers were disingenuous to the extent of dishonesty
>>>> on this specific point.
>>>>
>>>
>>> But the problem is the HHH that does that never answers, 
>>
>> So you forgot the details of this context?
>>
>> typedef void (*ptr)();
>> int HHH(ptr P);
>>
>> void Infinite_Loop()
>> {
>>    HERE: goto HERE;
>>    return;
>> }
>>
>> void Infinite_Recursion()
>> {
>>    Infinite_Recursion();
>>    return;
>> }
>>
>> void DDD()
>> {
>>    HHH(DDD);
>>    return;
>> }
>>
>> int DD()
>> {
>>    int Halt_Status = HHH(DD);
>>    if (Halt_Status)
>>      HERE: goto HERE;
>>    return Halt_Status;
>> }
>>
>> When HHH correctly emulates N steps of the
>> above functions none of them can possibly reach
>> their own "return" instruction and terminate normally.
>>
>>
> 
> No, you make a rash judgement, because you are lying to yourself on the 
> definitions.
> 
> Infinite_Loop and Infinite_Recursion, when directly run, will, in fact, 
> run forever, so as a decider, HHH can abort its simulation of them when 
> it proves that and return 0, as they will not ever reach the final state.

_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]

IT S ONLY THAT YOU INSIST ON THE DECEPTION OF THE
STRAWMAN ALWAYS CHANGING THE SUBJECT AWAY FROM THE
BEHAVIOR OF DDD CORRECTLY EMULATED BY HHH.


-- 
========== REMAINDER OF ARTICLE TRUNCATED ==========