Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: HHH(DDD) sees the exact same behavior pattern as
 HHH(Infinite_Recursion)
Date: Mon, 29 Jul 2024 19:16:29 -0500
Organization: A noiseless patient Spider
Lines: 219
Message-ID: <v89bcu$mrtd$1@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 30 Jul 2024 02:16:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f90a0d55b5a8d8d362f50b9fb3171851";
	logging-data="749485"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18CR8tHcqtTOT7keftKprZ5"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:qdrtreoGtnDj5C1wTXdhUCxqfxg=
In-Reply-To: <XDidnfUGgcz9gzX7nZ2dnZfqnPidnZ2d@brightview.co.uk>
Content-Language: en-US
Bytes: 11439

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.

> -  suppressing trace entries in H which would make it obvious that the 
> matching calls

I am not suppressing any freaking trace entries
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf

It is exactly as I have been saying all along
if you can freaking understand a 1.5 page trace
then adding a 200 more pages cannot possibly help.

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