Path: nntp.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: olcott <polcott333@gmail.com>
Newsgroups: comp.theory
Subject: Re: Title: A Structural Analysis of the Standard Halting Problem
 Proof
Date: Fri, 25 Jul 2025 15:02:16 -0500
Organization: A noiseless patient Spider
Lines: 82
Message-ID: <1060ns8$168i0$3@dont-email.me>
References: <105ht1n$36s20$1@dont-email.me>
 <eed26ffea811a639a76d0184321c57eafba746cd@i2pn2.org>
 <pI4fQ.147044$gKRf.71824@fx12.ams4> <105kvub$2q17h$1@dont-email.me>
 <105lg9k$3v8t8$6@dont-email.me> <105npl8$37i2t$1@dont-email.me>
 <105o4uu$g4mg$4@dont-email.me> <105q7nc$8slg$5@dont-email.me>
 <105qv4j$10rne$1@dont-email.me> <105t0cq$l7mf$2@dont-email.me>
 <105tg6d$1fr8n$7@dont-email.me> <105u8a0$r1ct$3@dont-email.me>
 <105u9a6$1jpvh$2@dont-email.me> <105vd5j$10108$1@dont-email.me>
 <10603io$138e1$1@dont-email.me> <10606p6$10108$2@dont-email.me>
 <1060bi4$138e1$11@dont-email.me> <1060kqt$10108$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 25 Jul 2025 20:02:17 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="361873d11261af9cc1f18e1b6d0d3dd4";
	logging-data="1253952"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18SgYz61pUCQTX52vjTS3GR"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:b2UrdUT3yX9DLARFXLqxBnbzjcY=
In-Reply-To: <1060kqt$10108$3@dont-email.me>
X-Antivirus-Status: Clean
X-Antivirus: Norton (VPS 250725-6, 7/25/2025), Outbound message
Content-Language: en-US

On 7/25/2025 2:10 PM, joes wrote:
> Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:
>> On 7/25/2025 10:10 AM, joes wrote:
>>> Am Fri, 25 Jul 2025 09:15:52 -0500 schrieb olcott:
>>>> On 7/25/2025 2:53 AM, joes wrote:
>>>>> Am Thu, 24 Jul 2025 16:41:26 -0500 schrieb olcott:
>>>>>> On 7/24/2025 4:24 PM, joes wrote:
>>>>>>> Am Thu, 24 Jul 2025 09:32:45 -0500 schrieb olcott:
> 
>>>>>>> Let's see: the call to HHH is #4, [waves hands], then another 4
>>>>>>> inside the next level of simulation, and after another 4 the first
>>>>>>> simulated HHH (the one called by the input, not the outermost
>>>>>>> simulator. We are now 3 levels in) decides that enough is enough
>>>>>>> and aborts,
>>>>>>
>>>>>> Thus immediate killing its simulated DDD and everything else that
>>>>>> HHH was simulating thus no simulated DDD or simulated HHH can
>>>>>> possibly ever return no matter how many or how few X86 instructions
>>>>>> that the executed HHH correctly emulates.
>>>>>> This is the part that you fail to understand or understand that I am
>>>>>> correct and disagree anyway.
>>>>
>>>>> You failed to understand I was talking about the first simulated HHH
>>>>> aborting, not the outermost simulator.
>>>>
>>>> *I am trying to get you to understand that is impossible*
>>>> The only HHH that can possibly abort is the outermost directly
>>>> executed one.
>>
>>> True if the input changes along with the simulator, but not if we
>>
>> The input is always the exact same sequence of machine language bytes.
> Oh, really now? I thought it referred to its simulator HHH by name.
> 

The actual code has always been based on an x86 emulator
that emulates finite strings of x86 machine code bytes.
I only refer to the C code and the names of its functions
because this code is probably too difficult for anyone here:

_DDD()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6892210000 push 00002192  // push DDD
[0000219a] e833f4ffff call 000015d2  // call HHH
[0000219f] 83c404     add esp,+04
[000021a2] 5d         pop ebp
[000021a3] c3         ret
Size in bytes:(0018) [000021a3]

>>> simulate the fixed input (that aborts after 4+4=8 instructions of DDD,
>>> when we encounter the second nested call to HHH) without prematurely
>>> aborting.
>> There exists no finite or infinite number of correctly emulated x86
>> instructions such that the emulated DDD ever reaches its emulated "ret"
>> instruction final halt state because the input to HHH(DDD) specifies
>> recursive emulation.

> Not if DDD is simulated by something other than HHH, such as an UTM.
> 

For three years everyone here acts like it is
impossible for them to understand that the correct
emulation of an input that calls its own emulator
HHH(DDD) can possibly be different then the emulation
of the same input that does not call its own emulator
HHH1(DDD).

_DDD()
[00002192] 55         push ebp
[00002193] 8bec       mov ebp,esp
[00002195] 6892210000 push 00002192  // push DDD
[0000219a] e833f4ffff call 000015d2  // call HHH
[0000219f] 83c404     add esp,+04
[000021a2] 5d         pop ebp
[000021a3] c3         ret
Size in bytes:(0018) [000021a3]


-- 
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer