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

Liste des GroupesRevenir à ca philosophy 
Sujet : Re: Title: A Structural Analysis of the Standard Halting Problem Proof
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theory
Date : 26. Jul 2025, 14:48:48
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <1062mc0$1ecv8$3@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
User-Agent : Mozilla Thunderbird
On 7/26/2025 3:05 AM, joes wrote:
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:>>>>
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.
 
_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]
When HHH emulates DDD then DDD calls HHH(DDD) based on
whatever code is at machine address 000015d2.
HHH correctly determines that no matter how many
instructions of DDD that it emulates that no DDD
can possibly ever reach its "ret" instruction final
halt state. This conclusively proves the input to
HHH(DDD) specifies non-halting behavior.

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.
Since the execution trace conclusively proves that it is correct
your mere intuition to the contrary is proven to be incorrect.

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?)
 
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Date Sujet#  Auteur
27 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal