Re: Title: A Structural Analysis of the Standard Halting Problem Proof

Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:

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.

But does DDD call whatever is behind the name "HHH" or does it call
the fixed code that aborts just before the second recursive call?
Because DDD calling a modified HHH' is a different program.

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 than the emulation of the
same input that does not call its own emulator HHH1(DDD).

It is not impossible to understand. It is wrong. If we prefix all
programs we pass to HHH with DDD, they should not be aborted as
if the were the same.
If HHH were a correct simulator, it would produce the same behaviour
as an UTM. (HHH1 is the same as HHH, right?)

--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.