Re: Richard seems to continue to blatantly lie -- I hope I am wrong about this

On 7/3/24 8:36 PM, olcott wrote:

On 7/3/2024 6:18 PM, Richard Damon wrote:

On 7/3/24 2:20 PM, olcott wrote:

_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call HHH(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]
>
DDD correctly emulated by any element of the infinite
set of every pure function HHH cannot possibly reach
its own ret instruction and halt. That HHH aborts its
emulation at some point or never aborts its emulation
cannot possibly change this.
>

>
No, you are just showing your ignorance.
>
It is IMPOSSIBLE to "Correctly Emulate" this input per the semantics of the x86 instruction set as given, as it referncee undefined memory.
>

 I already stipulated that the memory IS DEFINED with an
x86 emulator. Also you have seen that I have proven this.
https://liarparadox.org/HHH(DDD)_Full_Trace.pdf
 

And if you assume that stipulation for the emulation, then you are stipulating that the contents of ALL THE MEMORY is "part of the input".
Also, by stipulating that it is a x86 emulator, do you mean an actually complete emulator that fully emulates the input, or is it possible your PARTIAL/CONDITIONAL emulator that only emulates part of the behavior of the input.
If it is the later, then you can not just replace the call to the PARTIAL/CONDITIONAL emulator with the "unconditional" emulation that it just doesn't perform (since its emulation is conditional).
Thus even if you relax the requirement of the emulation from being based on the semantic of the (which prevents doing the subsitution, since that isn't in the semantic of the x86) you can't do it at the functional level as a conditional emualation is not the same as an unconditional emulation.
Also, since you have agreed that the "input" consists of ALL the contents of memory (or at least all that has HHH in it) that means that each of your different HHHs are looking at DIFFERENT inputs, and you can't talk about one of them showing another one is right, since they are working on different input.
That just blows are your work out of the water.
The fact that THIS HHH stops at some point before seeing the return, doesn't mean that if you give THIS INPUT to another decider that simulates longer, that it can't see that return, thus your "needed to" argument has broken, because the alternate deciders need to be given the EXACT SAME input, and thus they need to be put in some other unused location of memory to allow the original HHH to stay at its designated address.
In fact, we can even see if we put another copy of the code of HHH, that has been fully renamed to HHH1 it will see that DDD calls HHH(DDD) and that HHH will return (since it never sees DDD calling HHH1, it never needs to activate the self-simulation code).
Thus, we show that HHH didn't decide right, and even that it isn't an actual Computation