On 7/31/22 11:49 AM, olcott wrote:
> On 7/31/2022 10:26 AM, Paul N wrote:
>> On Saturday, July 30, 2022 at 10:22:08 PM UTC+1, olcott wrote:
>>> On 7/30/2022 3:16 PM, Richard Damon wrote:
>>>> Do you DENY that this means that H(P,P) since it is asking about P(P),
>>
>>> Yes I deny that H(P,P) is asking about P(P).
>>> A halt decider must compute the mapping from its inputs to an accept or
>>> reject state on the basis of the actual behavior that is actually
>>> specified by these inputs.
>>
>> Here is your problem in a nutshell. These two statements are totally
>> contradictory. How can you not see this?
>
> One would naturally assume that the behavior of the correctly simulated
> input to H(P,P) must necessarily be exactly the same as the behavior of
> the directly executed P(P).
>

Since that is what the CORRECT SIMULATION means, it would seem to be a
correct assumption.

Can you point out the first point of the difference between the directly
executed P(P) and the simulation of the input to H(P,P) and explain how
it is correct?

Failure to do so will be considered an admission that this statement is
just you making up lies, and then finding out that your bluff has been
called.

> When one checks the actual facts one sees that they do not have the same
> behavior because the sequence of instructions executed/simulated is not
> the same sequence.
>

And at what point does the sequence diverge?

Is that actually a CORRECT simulation of the input at that point?

> In the case where an input to H is specifically designed to thwart H by
> having a pathological relationship to H when H(P,P) correctly performs
> x86 emulation on its input this input would never stop running unless H
> aborts this simulation. This is verified because the behavior of the
> emulated P exactly matches the infinite recursion behavior pattern.

And here you go and get sucked in by your own lies.

We don't care about any H but the H that you claim to get the correct
answer.

That H aborts its simulation of the execution of P(P) because it THINKS
it sees evidence of infinite behavior. The problem is that it is
ignoring the fact that the call to H is to THIS SAME H that is deciding
to abort its simulation, and thus doesn't actually represent an infinite
recursive behavior BECAUSE H has decided (incorrectly) to abort its
simulation.

>
> Whereas the direct execution of P(P) specifies a different sequence of
> instructions. We can verify that the x86 emulation of the input to
> H(P,P) by H is correct on the basis that the line-by-line execution
> trace that this emulation produces exactly matches the line-by-line
> source code of P.
>

Again, where is the divergence in the sequence of instructions?

Note, your H makes a MISTAKE with its simulation of the call to H, as
the code to H IS part of the input to H, as there is no "barrier" in the
input definition that removes it. It should be noted that it you try to
exclude that code from the input you are going to run into issues,
either the input no longer is a correct and complete representation of
the behavior of the program (as ANY code would be allowed at the
location of H) or you are implicitly defining that it MUST be the code
that is actually there (it which case, it doesn't make a difference) or
you are implicitly defining it to some other code, in which case P isn't
the required computaton, as it needs to be calling an exact copy of the
decider it is designed to foil,

> void P(ptr x)
> {
>   int Halt_Status = H(x, x);
>   if (Halt_Status)
>     HERE: goto HERE;
>   return;
> }
>
>
> int main()
> {
>   P(P);
> }
>
>  _P()
> [00000f8f](01)  55             push ebp
> [00000f90](02)  8bec           mov ebp,esp
> [00000f92](01)  51             push ecx
> [00000f93](03)  8b4508         mov eax,[ebp+08]
> [00000f96](01)  50             push eax      // push 2nd argument
> [00000f97](03)  8b4d08         mov ecx,[ebp+08]
> [00000f9a](01)  51             push ecx      // push 1st argument
> [00000f9b](05)  e8fffcffff     call 00000c9f // calls H
> [00000fa0](03)  83c408         add esp,+08
> [00000fa3](03)  8945fc         mov [ebp-04],eax
> [00000fa6](04)  837dfc00       cmp dword [ebp-04],+00
> [00000faa](02)  7402           jz 00000fae
> [00000fac](02)  ebfe           jmp 00000fac
> [00000fae](02)  8be5           mov esp,ebp
> [00000fb0](01)  5d             pop ebp
> [00000fb1](01)  c3             ret
> Size in bytes:(0035) [00000fb1]
>
> _main()
> [0000102f](01)  55             push ebp
> [00001030](02)  8bec           mov ebp,esp
> [00001032](05)  688f0f0000     push 00000f8f // push P
> [00001037](05)  e853ffffff     call 00000f8f // call H
> [0000103c](03)  83c404         add esp,+04
> [0000103f](02)  33c0           xor eax,eax
> [00001041](01)  5d             pop ebp
> [00001042](01)  c3             ret
> Size in bytes:(0020) [00001042]
>
>  machine   stack     stack     machine    assembly
>  address   address   data      code       language
>  ========  ========  ========  =========  =============
> [0000102f][00101a6d][00000000] 55         push ebp
> [00001030][00101a6d][00000000] 8bec       mov ebp,esp
> [00001032][00101a69][00000f8f] 688f0f0000 push 00000f8f  // push P
> [00001037][00101a65][0000103c] e853ffffff call 00000f8f  // call executed P
> [00000f8f][00101a61][00101a6d] 55         push ebp       // enter
> executed P
> [00000f90][00101a61][00101a6d] 8bec       mov ebp,esp
> [00000f92][00101a5d][00000000] 51         push ecx
> [00000f93][00101a5d][00000000] 8b4508     mov eax,[ebp+08]
> [00000f96][00101a59][00000f8f] 50         push eax       // Push P
> [00000f97][00101a59][00000f8f] 8b4d08     mov ecx,[ebp+08]
> [00000f9a][00101a55][00000f8f] 51         push ecx       // Push P
> [00000f9b][00101a51][00000fa0] e8fffcffff call 00000c9f  // call executed H
> New slave_stack at:101b11

Why do we not see a trace of the actual code of H, THAT is part of the
execution trace of P(P)

>
> *Begin Local Halt Decider Simulation*   Execution Trace Stored at:111b19
> [00000f8f][00111b05][00111b09] 55         push ebp       // enter
> simulated P
> [00000f90][00111b05][00111b09] 8bec       mov ebp,esp
> [00000f92][00111b01][00101ad5] 51         push ecx
> [00000f93][00111b01][00101ad5] 8b4508     mov eax,[ebp+08]
> [00000f96][00111afd][00000f8f] 50         push eax       // push P
> [00000f97][00111afd][00000f8f] 8b4d08     mov ecx,[ebp+08]
> [00000f9a][00111af9][00000f8f] 51         push ecx       // push P
> [00000f9b][00111af5][00000fa0] e8fffcffff call 00000c9f  // call
> simulated H

And why does H not simulate the code of H, since THAT is part of the
CORRECT SIMULATION of the code of P.

Thus, your claim of "Correct Simulation" is FALSE.

> New slave_stack at:14c539
> [00000f8f][0015c52d][0015c531] 55         push ebp       // enter next
> simulated P
> [00000f90][0015c52d][0015c531] 8bec       mov ebp,esp
> [00000f92][0015c529][0014c4fd] 51         push ecx
> [00000f93][0015c529][0014c4fd] 8b4508     mov eax,[ebp+08]
> [00000f96][0015c525][00000f8f] 50         push eax       // push P
> [00000f97][0015c525][00000f8f] 8b4d08     mov ecx,[ebp+08]
> [00000f9a][0015c521][00000f8f] 51         push ecx       // push P
> [00000f9b][0015c51d][00000fa0] e8fffcffff call 00000c9f  // call next
> simulated H
> *Infinite Recursion Detected Simulation Stopped*

>
> With this older version of my halt decider it is easier to understand
> when H simply applies the infinite recursion behavior pattern to its input.
>
> (1) H(P, P) is called twice in sequence from the same machine address of
> P().
> (2) With the same arguments to H().
> (3) With no control flow instructions between the invocation of P() and
> its call to H(P,P).

And (3) is a FALSE RULE, so your argument is UNSOUND.

>
> [00000fa0][00101a5d][00000000] 83c408     add esp,+08
> [00000fa3][00101a5d][00000000] 8945fc     mov [ebp-04],eax
> [00000fa6][00101a5d][00000000] 837dfc00   cmp dword [ebp-04],+00
> [00000faa][00101a5d][00000000] 7402       jz 00000fae
> [00000fae][00101a61][00101a6d] 8be5       mov esp,ebp
> [00000fb0][00101a65][0000103c] 5d         pop ebp
> [00000fb1][00101a69][00000f8f] c3         ret   // return from executed P
> [0000103c][00101a6d][00000000] 83c404     add esp,+04
> [0000103f][00101a6d][00000000] 33c0       xor eax,eax
> [00001041][00101a71][00000018] 5d         pop ebp
> [00001042][00101a75][00000000] c3         ret
> Number of Instructions Executed(17219) == 257 Pages
>
> A halt decider must compute the mapping from its inputs to an accept or
> reject state on the basis of the actual behavior that is actually
> specified by these inputs, thus the actual behavior the input to H(P,P)
> that H correctly emulates must be the basis for its halt status decision.
>
> The above shows that the directly executed P(P) reaches its final state
> and halts whereas the correctly emulated input to H(P,P) never stops
> running until H aborts its simulation.