Re: DDD correctly emulated by H0 --- Why Lie? -- Repeat until Closure

On 6/28/24 8:28 AM, olcott wrote:

On 6/28/2024 6:44 AM, Richard Damon wrote:

On 6/27/24 11:25 PM, olcott wrote:

On 6/27/2024 6:34 AM, Richard Damon wrote:

>
That seems to be one of your biggest lies, you claim others are lying to try to disquise your own lies.
>
You can't show one thing that I have said that is FACTUALY INCORRCT (only that you disagre with them).
>
I have shown statements of your that ARE DEFINITIONALLY INCORRECT (even if you want to use a different definition, which just isn't allowed, and thus becomes a lie).

>
_DDD()
[00002172] 55               push ebp      ; housekeeping
[00002173] 8bec             mov ebp,esp   ; housekeeping
[00002175] 6872210000       push 00002172 ; push DDD
[0000217a] e853f4ffff       call 000015d2 ; call H0(DDD)
[0000217f] 83c404           add esp,+04
[00002182] 5d               pop ebp
[00002183] c3               ret
Size in bytes:(0018) [00002183]
>
The call from DDD to H0(DDD) when DDD is correctly
emulated by x86 emulator H0 cannot possibly return.
>
>

>
You are still using sloppy definition to spread your deceit.
>

 The call from DDD to H0(DDD) when N steps of DDD are correctly
emulated by any pure function x86 emulator H0 cannot possibly
return.

So?
When Completely correctly emulated by an actual correct emulator it will because you have said that your H0 WILL abort it emulation and return, and thus not do an actually correct emulation by the x86 instruction semantics, since part of the semantics of every instruction is that the next instruction in sequence WILL be executed.

 The behavior of the directly executed DDD() is irrelevant
because that is not the behavior of the input. Deciders
compute the mapping from their actual finite string input
to an output by a sequence of finite string transformations.

Of course it is. Why isn't it.
Your N Step Emulation of the input (with N being determined by the decider) CAN'T be the "behavior" of the input, as it isn't determined by just the input itself.

 In this case the sequence is the line-by-line execution
trace of the behavior of DDD correctly emulated by H0.

Which is INOCRRECT by being INCOMPLETE when the semantic that the input was defined to have requries completeness.

 The behavior of this input must include and cannot ignore
the recursive emulation specified by the fact that DDD is
calling its own emulator. That people think they can just
pretend that this is not happening is ridiculous.
 

Right, and as such, must go into H0, so that is part of the input, and thus can not be changed when talking about THE INPUT.;
So, with THIS H0 as the input, the FULL behavior will be to reach the final state, unless you admit to lying that H1 did reach that same ending, and that H0(DDD) does return.