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

On 6/10/24 9:52 AM, olcott wrote:

On 6/10/2024 2:09 AM, Fred. Zwarts wrote:

Op 10.jun.2024 om 07:17 schreef olcott:

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*
>
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).
>
_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*
>
H does not ignore that instruction and simulates itself simulating D.
The simulated H outputs its own execution trace of D.
>
>

On 05.jun.2024 at 15:59 (CET) olcott proved that in the example
>
 > int main()
 > {
 >    Output("Input_Halts = ", HH(main,(ptr)0));
 > }
>
main halts and HH reported a non-halting behaviour. This means that when HH is used as a test for halting, it produces a false negative.
>

 I just proved that D correctly simulated by H has different
behavior than the directly executed D(D) and you ignored it.
 

Nope. You just proved that your H doesn't correct simulatie its input, because it doesn't correctly simulate the CALL H instruction.
The CALL H innstruction, to be correctly simulated, must be followed by a simulation of the instructions that follow.
SInce that ISN'T what H did, at least per your listing, it just never did a correct simulation.