Path: ...!weretis.net!feeder9.news.weretis.net!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: olcott Newsgroups: comp.theory Subject: Re: HHH(DDD) sees the exact same behavior pattern as HHH(Infinite_Recursion) Date: Sun, 28 Jul 2024 15:10:41 -0500 Organization: A noiseless patient Spider Lines: 114 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sun, 28 Jul 2024 22:10:42 +0200 (CEST) Injection-Info: dont-email.me; posting-host="e780778616be4582a0134c2484eeadc2"; logging-data="98619"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/0GvtHohPnwCpOp8kcuius" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:t2/Zsg0ilPc5fc5lBUnX/S8LOo8= In-Reply-To: Content-Language: en-US Bytes: 6634 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 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. Until you do that YOU ARE ACTING STUPIDLY. Go back an try again. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer