Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: HHH(DDD) sees the exact same behavior pattern as
 HHH(Infinite_Recursion) unless it can abort.
Date: Sun, 28 Jul 2024 17:04:48 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <273ca7620e330517c5dfdff6df82fcea2c201ebc@i2pn2.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 28 Jul 2024 21:04:48 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="667011"; 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: <v868k2$309r$1@dont-email.me>
Content-Language: en-US
Bytes: 7508
Lines: 135

On 7/28/24 4:10 PM, olcott wrote:
> 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.
> 
> We are seeing that Infinite_Recursion() does not halt
> and seeing that Infinite_Recursion() shows the exact
> same non-halting behavior pattern as DDD correctly
> emulated by HHH.

So, you are stipulating that HHH will NEVER abort is simulation?

That is the only way that the two traces are even close.

For HHH to ignore the possible conditionality of code activated by the 
call to HHH(DDD) inside of DDD, it has to be stipulated that there is none.

> 
> Until you do that YOU ARE ACTING STUPIDLY.
> Go back an try again.
> 

No, YOU are the one acting deceptively as well as stupidly,

You are just demonstrating how totally ignorant you are of the fields 
that you try to talk about, and how little you value truth.

The ONLY way to even partially equate the behavior of 
Infinite_Recurstion and DDD / HHH(DDD) is for HHH to be an UNCONDITIONAL 
emulator of DDD.

I guess you just don't know what unconditional means. It doens't mean it 
keeps on going until it shows something, it meens it keeps on going 
DISPITE anything that happens.

Of course, understanding conditionals means understanding how logic 
works, which has been proven to be beyond your ability,