Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: "Fred. Zwarts" <F.Zwarts@HetNet.nl>
Newsgroups: comp.theory
Subject: Re: HHH(DDD) sees the exact same behavior pattern as
 HHH(Infinite_Recursion)
Date: Tue, 30 Jul 2024 10:17:39 +0200
Organization: A noiseless patient Spider
Lines: 178
Message-ID: <v8a7j5$uejg$2@dont-email.me>
References: <v80h07$2su8m$3@dont-email.me> <v82bi4$39v6n$4@dont-email.me>
 <v82tr5$3dftr$2@dont-email.me> <v82vtl$3dq41$2@dont-email.me>
 <v830hg$3dftr$9@dont-email.me> <v83des$2nhr$1@news.muc.de>
 <KUidnalBUcYWDjj7nZ2dnZfqn_ednZ2d@brightview.co.uk>
 <v84d5a$3p1o0$1@dont-email.me> <v84tpk$3rc90$2@dont-email.me>
 <v85kdi$3v9fb$2@dont-email.me> <v8659q$2409$3@dont-email.me>
 <v868k2$309r$1@dont-email.me> <v87gcm$cmps$1@dont-email.me>
 <v883vq$g39i$2@dont-email.me> <v88r09$ju20$5@dont-email.me>
 <XDidnfUGgcz9gzX7nZ2dnZfqnPidnZ2d@brightview.co.uk>
 <v89bcu$mrtd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 30 Jul 2024 10:17:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a40890b8ee07f8c0ea610e1bb666f251";
	logging-data="998000"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18TsAse45cxb2T/Y7p1yQp/"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:E3RL7gDiWSKZj76cAth15fsDMbo=
In-Reply-To: <v89bcu$mrtd$1@dont-email.me>
Content-Language: en-GB
Bytes: 10359

Op 30.jul.2024 om 02:16 schreef olcott:
> On 7/29/2024 5:57 PM, Mike Terry wrote:
>> On 29/07/2024 20:36, Fred. Zwarts wrote:
>>> Op 29.jul.2024 om 15:03 schreef olcott:
>>>> On 7/29/2024 2:29 AM, Fred. Zwarts wrote:
>>>>> Op 28.jul.2024 om 22:10 schreef olcott:
>>>>>> On 7/28/2024 2:14 PM, Fred. Zwarts wrote:
>>>>>>> Op 28.jul.2024 om 16:25 schreef olcott:
>>>>>>>> On 7/28/2024 2:59 AM, Fred. Zwarts wrote:
>>>>>>>>> Op 28.jul.2024 om 05:15 schreef olcott:
>>>>>>>>>> On 7/27/2024 7:40 PM, Mike Terry wrote:
>>>>>>>>>>> On 27/07/2024 19:14, Alan Mackenzie wrote:
>>>>>>>>>>>> olcott <polcott333@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Stopping running is not the same as halting.
>>>>>>>>>>>>> DDD emulated by HHH stops running when its emulation has 
>>>>>>>>>>>>> been aborted.
>>>>>>>>>>>>> This is not the same as reaching its ret instruction and 
>>>>>>>>>>>>> terminating
>>>>>>>>>>>>> normally (AKA halting).
>>>>>>>>>>>>
>>>>>>>>>>>> I think you're wrong, here.  All your C programs are a stand 
>>>>>>>>>>>> in for
>>>>>>>>>>>> turing machines.  A turing machine is either running or 
>>>>>>>>>>>> halted. There is
>>>>>>>>>>>> no third state "aborted".  An aborted C program certainly 
>>>>>>>>>>>> doesn't
>>>>>>>>>>>> correspond with a running turing machine - so it must be a 
>>>>>>>>>>>> halted turing
>>>>>>>>>>>> machine.
>>>>>>>>>>>>
>>>>>>>>>>>> So aborted programs are halted programs.  If you disagree, 
>>>>>>>>>>>> perhaps you
>>>>>>>>>>>> could point out where in my arguments above I'm wrong.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Aborting is an action performed by a simulator, not the TM 
>>>>>>>>>>> being simulated.
>>>>>>>>>>>
>>>>>>>>>>> If we want to count "aborted" as some kind of final status, 
>>>>>>>>>>> it will have to be the status of a specific /PARTIAL 
>>>>>>>>>>> SIMULATOR's/ simulation of a given computation.  That's not a 
>>>>>>>>>>> property of the computation itself, as different partial 
>>>>>>>>>>> simulators can simulate the same computation and terminate 
>>>>>>>>>>> for different reasons.  Like HHH(DDD) aborts, while UTM(DDD) 
>>>>>>>>>>> simulates to completion and so the final simulation status is 
>>>>>>>>>>> halts. [Neither of those outcomes contradict the fact that 
>>>>>>>>>>> the computation DDD() halts.]
>>>>>>>>>>>
>>>>>>>>>>> If some partial simulator halts when simulating a computation 
>>>>>>>>>>> [as with UTM(DDD)] that implies the computation DDD() halts. 
>>>>>>>>>>> But if the simulator aborts, it doesn't say that much (in and 
>>>>>>>>>>> of itself) about whether the /computation/ halts.  The 
>>>>>>>>>>> halting problem statement is not concerned with simulations 
>>>>>>>>>>> or how the simulations end.
>>>>>>>>>>>
>>>>>>>>>>> Every time anyone in these PO threads says "halts" it ought 
>>>>>>>>>>> to be 100% clear to everyone whether the computation itself 
>>>>>>>>>>> is being discussed, or whether some simulation final status 
>>>>>>>>>>> is intended. (But that's far from being the case!)  Since the 
>>>>>>>>>>> halting problem is concerned with computations halting and 
>>>>>>>>>>> not how partial simulations are ended, I suggest that PO 
>>>>>>>>>>> explicitly make clear that he is referring to simulations, 
>>>>>>>>>>> whenever that is the case. It seems reasonable that readers 
>>>>>>>>>>> seeing "halts" with no further clarification can interpret 
>>>>>>>>>>> that as actual computation behaviour, as that is how the term 
>>>>>>>>>>> is always used in the literature.  Same with other terms like 
>>>>>>>>>>> "reach"...
>>>>>>>>>>>
>>>>>>>>>>> So when PO says "DDD simulated by HHH cannot reach its final 
>>>>>>>>>>> ret instruction" is he talking about the computation DDD() 
>>>>>>>>>>> [as defined mathematically], or its simulation by HHH?  He 
>>>>>>>>>>> means the latter, but its far from clear, I'd say!  [I think 
>>>>>>>>>>> most readers now have come around to reading it as a 
>>>>>>>>>>> statement about simulations rather than the actual 
>>>>>>>>>>> computation, which totally changes things...]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Mike.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _DDD()
>>>>>>>>>> [00002163] 55         push ebp      ; housekeeping
>>>>>>>>>> [00002164] 8bec       mov ebp,esp   ; housekeeping
>>>>>>>>>> [00002166] 6863210000 push 00002163 ; push DDD
>>>>>>>>>> [0000216b] e853f4ffff call 000015c3 ; call HHH(DDD)
>>>>>>>>>> [00002170] 83c404     add esp,+04
>>>>>>>>>> [00002173] 5d         pop ebp
>>>>>>>>>> [00002174] c3         ret
>>>>>>>>>> Size in bytes:(0018) [00002174]
>>>>>>>>>>
>>>>>>>>>> It is a verified fact that DDD emulated by HHH 100% exactly
>>>>>>>>>> and precisely according to the actual x86 semantics of
>>>>>>>>>> the emulated code including the recursive call that causes
>>>>>>>>>> HHH to emulate itself emulating DDD cannot possibly get
>>>>>>>>>> past it own 0000216b machine address.
>>>>>>>>>>
>>>>>>>>>> *Anyone as much as hinting otherwise is not being truthful*
>>>>>>>>>> If we remove all of the problematic code then this same
>>>>>>>>>> trace still occurs until it crashes from OOM error.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No matter how much olcott wants it to be correct, or how many 
>>>>>>>>> times olcott repeats that it is correct, it does not change the 
>>>>>>>>> fact that such a simulation is incorrect, because it is unable 
>>>>>>>>> to reach the end.
>>>>>>>>
>>>>>>>> It is ridiculously stupid to expect the correct emulation
>>>>>>>> of a non-halting input to end.
>>>>>>>
>>>>>>> Irrelevant nonsense ignored.
>>>>>>> We are not discussing a non-halting HHH, 
>>>>>>
>>>>>> No we are not. Please don't act so stupidly.
>>>>>
>>>>> Why are you contradicting yourself so often? It does not look very 
>>>>> clever.
>>>>> You were talking about an infinite set of HHH, some of which abort, 
>>>>> some of which do not abort.
>>>>
>>>> *This is all that I am willing to talk about with you*
>>>> Every change of subject away from this point will be
>>>> construed as the dishonest dodge of the strawman deception.
>>>>
>>>> You didn't even bother to look at how HHH examines the
>>>> execution trace of Infinite_Recursion() to determine that 
>>>> Infinite_Recursion() specifies non-halting behavior.
>>>>
>>>> Because of this you cannot see that the execution trace
>>>> of DDD correctly emulated by DDD is essentially this same
>>>> trace and thus also specifies non-halting behavior.
>>>
>>> That is only because you are cheating, by hiding the conditional 
>>> branch instructions of HHH, which should follow the call instruction 
>>> into HHH.
>>> HHH simulating itself is more like
>>>
>>> void Finite_Recursion (int N) {
>>>    if (N > 0) Finite_Recursion (N - 1);
>>> }
>>>
>>> You never bothered to think about it.
>>
>> Also there is the crucial difference that Infinite_Recursion() trace 
>> is a trace for a single x86 processor.  The HHH/DDD trace is not a 
>> single processor trace, as it contains entries for multiple virtual 
>> x86 processors, all merged into one.  There are all sorts of argument 
>> that can be applied to the simple single x86 processor trace scenario, 
>> that simply don't work when transferred to a 
>> multi-processor-simulation merged trace.  PO doesn't understand these 
>> differences, and has said there is NO difference!  He also 
>> deliberately tries to hide these difference, by making his trace 
>> output resemble a single-processor trace as far as he can:
>>
> 
> The simple fact that you continue to ignore is that DDD
> is correctly emulated by DDD according to the semantics
> of the x86 instructions of DDD and HHH that includes that
> DDD does call HHH(DDD) in recursive emulation that will
> never stop running unless aborted.

HHH aborts, so it a halting programs.
Dreaming of a HHH that never stops is not a substitute for logic, but 
irrelevant
There is no need to abort the simulation of a halting program. It is 
against the semantics of the x86 language to skip instructions of a 
halting program. Your simulation fails by your own criterion.

No matter how much olcott wants it to be correct, or how many times 
========== REMAINDER OF ARTICLE TRUNCATED ==========