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

On 6/5/25 12:45 PM, olcott wrote:

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.

And why wasn't the CALL instruction correctly emulated?
If you stopped before it, then the push wasn't correctly emulated, as the last part of every instruction (except halt) is to execute the next instruction at the contents of the Program Counter.

 

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.

You aree the one with a psychosis.
The only way to prove that an input is non-halting, BY DEFINITION, is to show that the correct operation of the program (as possible shown by correct simulation) would never stop.
The decider doesn't need to do that, but if it doesn't, then its simulation is not the needed proof.

 

>
*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.

Why not?
That is what the definition of the x86 processor says will happen, and thus what a correct emulation of the code will do.
You problem is you lie to yourself about what things mean, and are too stupid tp see that transparentcy of those lies.
All you are doing it probing how IGNORANT you are of what you are talking about, and that you are will to just lie about it, since you just don't care about what is correct or truthful.

>
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.