Re: H(D,D) cannot even be asked about the behavior of D(D) V3 ---IGNORING ALL OTHER REPLIES

On 6/16/24 8:47 AM, olcott wrote:

On 6/16/2024 2:53 AM, Mikko wrote:

On 2024-06-15 16:22:09 +0000, olcott said:
>

On 6/13/2024 8:24 PM, Richard Damon wrote:
 > On 6/13/24 11:32 AM, olcott wrote:
 >>
 >> It is contingent upon you to show the exact steps of how H computes
 >> the mapping from the x86 machine language finite string input to
 >> H(D,D) using the finite string transformation rules specified by
 >> the semantics of the x86 programming language that reaches the
 >> behavior of the directly executed D(D)
 >>
 >
 > Why? I don't claim it can.
>
The first six steps of this mapping are when instructions
at the machine address range of [00000cfc] to [00000d06]
are simulated/executed.
>
After that the behavior of D correctly simulated by H diverges
from the behavior of D(D) because the call to H(D,D) by D
correctly simulated by H cannot possibly return to D.
>
_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]

>
When you put "V2" or "V3" or something similar on the subject line
you should tell what is different from the original version.
>

 I ask what are the steps
I provide 6 steps and then ask what are the next steps.
I provide all of the steps.
 

but the NEXT step is the call H instruction, follwed by the simulation of the insturciton of H, at which point you hit problem.
You seem to be trying to define that the "input" is independent of the H, but then you simulator CAN'T BE CORRECT, as it needs to process behavior of the input that hasn't been given.
You try to weasle by saying it can use the contents of the memory that is their, but then it is no longer looking at the behavior specified by the input if that has been excluded as part of the input, so that is just a lie.
That means, that the input must actually include all the code of H (and everything H calls) and thus, you can't change the code of H that D calls when you perform your proof, but need to make a new function, like H1, that you do your variations over.
And, when you do that, it turns out that the new Hs that simulate enough longer can see that their correct simulation will reach that final state, and thus your claims are shown to be just a lie.
The problem come to a head when we look at the definition of D, as described in Linz's H^. The basic definition of what H^ is supposed to be doing, is to ask H to decide on the behavior of H^ applied to a description of itself, and then do the opposite.
Since your D does that "ask H" part by calling H(D,D), then that MUST be the method of asking H about the behavior of THIS D, and thus there must be sufficient information in that input to do that, which means, that this input needs to represent the WHOLE PROGRAM, and thus includes a copy of the H it was using, and specifically a copy of THAT H, not some other one with a different behavior.