Re: DDD emulated by HHH diverges from DDD emulated by HHH1

On 6/5/2025 6:29 AM, Richard Damon wrote:

On 6/4/25 10:15 PM, olcott wrote:

On 6/4/2025 8:48 PM, Richard Damon wrote:

On 6/4/25 10:52 AM, olcott wrote:

On 6/4/2025 1:54 AM, Mikko wrote:

On 2025-06-03 19:57:09 +0000, olcott said:
>

On 6/3/2025 2:37 AM, Mikko wrote:

On 2025-06-02 15:52:53 +0000, olcott said:
>

DDD correctly emulated by HHH diverges from DDD
correctly emulated by HHH1 as soon as HHH begins
emulating itself emulating DDD, marked below.

>
The DDD emulated (correctly or otherwise) by HHH is the same DDD as
the one emulated (correctly or otherwise) so both specify the same
behaviour.

>
No they do not. When DDD calls its own emulator its behavior
is different than when DDD calls another different emulator.

>
If the input string does not unambiguously specify one and only one
behaviour it is incorrectly encoded and not a valid input string.
The halting problem of Truing machines requires that every pair of
a Turing macnine and input is descibed so that the behaviour to
be decided about is the only behaviour that meets to the description.
>

>
The code proves what it proves.
>
_DDD()
[00002183] 55             push ebp
[00002184] 8bec           mov ebp,esp
[00002186] 6883210000     push 00002183 ; push DDD
[0000218b] e833f4ffff     call 000015c3 ; call HHH
[00002190] 83c404         add esp,+04
[00002193] 5d             pop ebp
[00002194] c3             ret
Size in bytes:(0018) [00002194]
>
_main()
[000021a3] 55             push ebp
[000021a4] 8bec           mov ebp,esp
[000021a6] 6883210000     push 00002183 ; push DDD
[000021ab] e843f3ffff     call 000014f3 ; call HHH1
[000021b0] 83c404         add esp,+04
[000021b3] 33c0           xor eax,eax
[000021b5] 5d             pop ebp
[000021b6] c3             ret
Size in bytes:(0020) [000021b6]
>
  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  ========== =============
[000021a3][0010382d][00000000] 55         push ebp      ; main()
[000021a4][0010382d][00000000] 8bec       mov ebp,esp   ; main()
[000021a6][00103829][00002183] 6883210000 push 00002183 ; push DDD
[000021ab][00103825][000021b0] e843f3ffff call 000014f3 ; call HHH1
New slave_stack at:1038d1

>
So what "simulation" is the above? It seems that you are showing a trace from x86, not what HHH is doing.
>

>
What I am showing is DDD emulated by HHH1
side-by-side with DDD emulated by HHH

 No you are not, as you don't c
 

>
*They initially match up*
DDD emulated by HHH1              DDD emulated by HHH
[00002183] push ebp               [00002183] push ebp
[00002184] mov ebp,esp            [00002184] mov ebp,esp
[00002186] push 00002183 ; DDD    [00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH    [0000218b] call 000015c3 ; HHH
*The matching is now all used up*

 And that this point, NEITHER of them actually correctly emulate their input, at least not by the output that they generate.
 

When I say correctly emulated input I mean
that every instruction that has been emulated
so far was correctly emulated.

Thus, you "argument" is just based on lies.
 

You argument is based on the psychosis
of insisting that a non-terminating input
be simulated completely otherwise every
single steps of this simulation is wrong.

>
*Then DDD emulated by HHH does something*
*that DDD emulated by HHH1 never does*
*it emulates DDD all over again*
[00002183] push ebp      ;
[00002184] mov ebp,esp   ;
[00002186] push 00002183 ; DDD
[0000218b] call 000015c3 ; HHH
>

 But that ISN'T what a correct emulation of the input should do, and thus AGAIN, I point out that you "logic" is built on the concept that lying is valid.
 A correct emulation of the input to HHH and HHH1 will be IDENTICAL, as both use the same HHH in them. (One point you miss is that just the code of the C function DDD is INVALID as an input, but when seens as a program automatically include all the code it uses, that is the code of the HHH that gives the answer you claim it correctly gives.)
 This emulation will exaxtly follow the path of the directly executed DDD, into HHH, and see it emulating DDD, and never again "directly execute" the code of DDD in that context. Thus, a "correct emulation" of this input will NEVER show the creation of a new context as in the path of emulation, as at the x86 processor level, this just doesn't happen.
 We WILL see the operations, that at the meta-level can be interpreted as setting up such a context and the emulation of the program in the meta- level, but that is NOT something in the actual context of the emulation of the input.
 Your random changing of levels of abstrction just get you the wrong answers, as you neglect some of the actions that are happening at the outer levels of abstraction that do affect the behavior.
 Perhaps in words you might understand, your "emulation" LIES about the behavior of the HHH that it sees getting called, PRESUMING for the meta- analysis that it isn't actually the code that is there, but that it is just a pure emulator, and by starting with this LIE, it can show that the results will be non-halting.
 But since that IS a lie, the proof isn't valid, but just another of our multitude of lies showing you don't know what you are talking about.

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