Re: Proof that DD correctly simulated by HH has different behavior than DD(DD) STEP(1)

On 6/10/24 1:17 AM, olcott wrote:

On 6/9/2024 1:33 AM, Fred. Zwarts wrote:

Op 08.jun.2024 om 20:47 schreef olcott:

Before we can get to the behavior of the directly executed
DD(DD) we must first see that the Sipser approved criteria
have been met:
>
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its input D
until H correctly determines that its simulated D would never
stop running unless aborted then
>
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words10/13/2022>
>
On 10/14/2022 7:44 PM, Ben Bacarisse wrote:
 > I don't think that is the shell game. PO really /has/ an H
 > (it's trivial to do for this one case) that correctly determines
 > that P(P) *would* never stop running *unless* aborted.
>
Try to show how this DD correctly simulated by any HH ever
stops running without having its simulation aborted by HH.

>
Stopping at your first error. So, we can focus on it. Your are asking a question that contradicts itself.
A correct simulation of HH that aborts itself, should simulate up to the point where the simulated HH aborts. That is logically impossible. So, either it is a correct simulation and then we see that the simulated HH aborts and returns, or the simulation is incorrect, because it assumes incorrectly that things that happen (abort) do not happen.
A premature conclusion.
>
>

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

So, I guess you are admitting that you claim it as a verified fact is just a LIE.

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

So, I guess you are admitting that this means that "D correctly simulated by H" is NOT a possible equivalent statement for the behavior of the direct execution of the input as required by the Halting Problem, so you admit you have been LYING every time you imply that it is.

 _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, H can, and must, simulate the call instruction correctly.
Your problem is that it turns out that the only way that a correct simulation by H to be an actual correct simulation that shows halting behavior, it can't answer and be a decider.

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

But your H DOES ignore the CORRECT behavior of that instruction, as a correct simulation of that instruction (by what ever type of simulation you want to do) must either continue it trace inot the function H (which none of your publish traces of the resutls of the simulation H does do) if the simulation instruction level, or it must show the effective behavior of the actaul function H, which is to return 0 (since you claim you H is correct, and correct to return 0).
Neither of these is what your "correct simulation" of the input does, so it can not be a correct simulation of the input. Your H just doesn't "correctly simulate" that call instruction, but does invalid logic to conclude the wrong answer.
It seems impossible for you claim that you have looked at the trace of H acuallly doing the x86 instruction trace of H to show that it was correctly determining what you claim, as your "250 page" trace turns out not to be that trace, and you admit you didn't look at it closely, and you JUST think you figured out how to get such a trace out.
Thus, you could NOT have verified it 3 years ago.
So, you have just been caught in a LIE.