On 6/10/24 11:39 AM, olcott wrote:

On 6/10/2024 10:35 AM, joes wrote:

A simulation must have the same behaviour.

[D correctly simulated by H proved for THREE YEARS ---]

*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*
*No one has verified the actual facts of this for THREE YEARS*

On 5/29/2021 2:26 PM, olcott wrote: https://groups.google.com/g/comp.theory/c/dTvIY5NX6b4/m/cHR2ZPgPBAAJ

THE ONLY POSSIBLE WAY for D simulated by H to have the same
behavior as the directly executed D(D) is for the instructions
of D to be incorrectly simulated by H (details provided below).

The only way for H to correctly simulate the input is to simulate the
call H (and following) exactly like the direct execution did.

_D()
[00000cfc](01) 55          push ebp
[00000cfd](02) 8bec        mov ebp,esp
[00000cff](03) 8b4508      mov eax,[ebp+08]
[00000d02](01) 50          push eax       ; push D [00000d03](03) 8b4d08      mov ecx,[ebp+08]
[00000d06](01) 51          push ecx       ; push D [00000d07](05) e800feffff  call 00000b0c  ; call H
[00000d0c](03) 83c408      add esp,+08
[00000d0f](02) 85c0        test eax,eax
[00000d11](02) 7404        jz 00000d17
[00000d13](02) 33c0        xor eax,eax
[00000d15](02) eb05        jmp 00000d1c
[00000d17](05) b801000000  mov eax,00000001
[00000d1c](01) 5d          pop ebp
[00000d1d](01) c3          ret
Size in bytes:(0034) [00000d1d]

In order for D simulated by H to have the same behavior as the
directly executed D(D) H must ignore the instruction at machine
address [00000d07]. *That is an incorrect simulation of D*

No, it must SIMULATE that instruction, EXACTLY like the processor would
execute it, and then continue simulating the code of H.

H does not ignore that instruction and simulates itself simulating D.
The simulated H outputs its own execution trace of D.

No, it simulates the instructions the simulator it is supposed to be simiulating is simulating.

H is incorrect as it isn't simulating the actual x86 instructons
presented ot it. It has "skipped" to a different execution environment,
in contadiction to the definition.

The directly executed D(D) reaps the benefit of D correctly
simulated by H proving that *its input never halts*

No, it has reapd the benefit of H INCORRECTLY simulating the input, and
using unsound logic to incorrectly determine the behavior of the input.

Begin Local Halt Decider Simulation at Machine Address:cfc ..[00000cfc][00211839][0021183d](01)  55          push ebp ..[00000cfd][00211839][0021183d](02)  8bec        mov ebp,esp ..[00000cff][00211839][0021183d](03)  8b4508      mov eax,[ebp+08] ..[00000d02][00211835][00000cfc](01)  50          push eax      ; push D
..[00000d03][00211835][00000cfc](03)  8b4d08      mov ecx,[ebp+08] ..[00000d06][00211831][00000cfc](01)  51          push ecx      ; push D
..[00000d07][0021182d][00000d0c](05)  e800feffff  call 00000b0c ; call H This call to H is simulated H.
We can tell that it is the simulated H is providing this
trace because it has a different virtual machine stack.
The simulated H derives this execution trace of D:

And thus isn't what the top level H is supposed to have done.

WHere in the x86 instruction specificatin do you find this behavior
specified.

Your ignoring of all these comments, just proves that you understand
this is incorrect, but you realize you need to push this LIE to try to
push your FALSE IDEAS forward.

    machine   stack     stack     machine          assembly
    address   address   data      code             language
    ========  ========  ========  ===============  ============= ..[00000cfc][0025c261][0025c265](01)  55          push ebp ..[00000cfd][0025c261][0025c265](02)  8bec        mov ebp,esp ..[00000cff][0025c261][0025c265](03)  8b4508      mov eax,[ebp+08] ..[00000d02][0025c25d][00000cfc](01)  50          push eax      ; push D
..[00000d03][0025c25d][00000cfc](03)  8b4d08      mov ecx,[ebp+08] ..[00000d06][0025c259][00000cfc](01)  51          push ecx      ; push D
..[00000d07][0025c255][00000d0c](05)  e800feffff  call 00000b0c ; call H Infinitely Nested Simulation Detected Simulation Stopped

Because the H(D,D) that D(D) calls correctly recognizes the its input
DOES NOT HALT, it correctly aborts the simulation of this input causing
the directly executed D(D) to halt.

Except that its input DOES Halt, so you are just showing that in YOUR
LOGIC, it is ok to claim false answer are correct and that halting
prograrm are non-halting.

You are just living the LIAR Paradox.

I proved that D simulated by H can only have the same behavior as the directly executed D(D) when D is simulated by H incorrectly.

Nope, you have proven that H doesn't correctly simulate its input.

Prehaps because you just don't understand the meaning of the word
"Correct" because you don't understand what "Truth" means.

This requires D simulated by H to skip over the machine address
[00000d07] and not call H(D,D) to simulate itself again.
D simulated by H does not do that. It simulates itself simulating D.

Why do you say that?

All you are doing is proving that H incorrectly simulates its input, as
it never ACTUALLY simulated the call H, and then treced the code OF H
that it saw, instead it traced that code that the H it is supposed to be simulating saw, which means it shifted into a world of fantasy and make-beleive.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)