Re: DDD emulated by HHH diverges from DDD emulated by HHH1

On 6/6/25 4:11 PM, olcott wrote:

On 6/6/2025 2:36 PM, joes wrote:

Am Fri, 06 Jun 2025 14:18:26 -0500 schrieb olcott:

On 6/6/2025 2:14 PM, joes wrote:

Am Fri, 06 Jun 2025 12:35:40 -0500 schrieb olcott:

On 6/6/2025 12:26 PM, joes wrote:

Am Wed, 04 Jun 2025 21:15:52 -0500 schrieb olcott:

On 6/4/2025 8:48 PM, Richard Damon wrote:

On 6/4/25 10:52 AM, olcott wrote:

On 6/4/2025 1:54 AM, Mikko wrote:

On 2025-06-03 19:57:09 +0000, olcott said:

On 6/3/2025 2:37 AM, Mikko wrote:

On 2025-06-02 15:52:53 +0000, olcott said:

>

The DDD emulated (correctly or otherwise) by HHH is the same
DDD as the one emulated (correctly or otherwise) so both
specify the same behaviour.

>
No they do not. When DDD calls its own emulator its behavior is
different than when DDD calls another different emulator.

>

Their code is the same and has the same meaning. DDD always calls
HHH.

>
You overlooked this.

>
Please cut the above if you read it.
>

If the input string does not unambiguously specify one and only
one behaviour it is incorrectly encoded and not a valid input
string. The halting problem of Truing machines requires that
every pair of a Turing macnine and input is descibed so that the
behaviour to be decided about is the only behaviour that meets to
the description.
>

The code proves what it proves.

>

So what "simulation" is the above? It seems that you are showing a
trace from x86, not what HHH is doing.
>

What I am showing is DDD emulated by HHH1 side-by-side with DDD
emulated by HHH
>
*They initially match up*
DDD emulated by HHH1              DDD emulated by HHH [00002183]
push ebp               [00002183] push ebp [00002184] mov ebp,esp
[00002184] mov ebp,esp [00002186] push 00002183 ; DDD    [00002186]
push 00002183 ; DDD [0000218b] call 000015c3 ; HHH    [0000218b]
call 000015c3 ; HHH *The matching is now all used up*
>
*Then DDD emulated by HHH does something*
*that DDD emulated by HHH1 never does*
*it emulates DDD all over again*

>
HHH1 also does that, and more, because it doesn't abort.
>

HHH emulates itself emulating DDD HHH1 NEVER emulates itself

I didn't say that it did. Like HHH it simulates HHH simulating DDD.
>

HHH1(DDD) simulates DDD that eventually halts. HHH(DDD) simulates DDD
that cannot possibly halt.

 

There is no "DDD that doesn't halt".

 You change the words that I said before
rebutting these changed words.
 DDD correctly emulated by HHH cannot possibly
reach its own emulated "return" instruction
final state.

Which is an irrelevent strawman.

 The input to HHH(DDD) SPECIFIES NON-HALTING BEHAVIOR.
That the caller of HHH(DDD) halts is none of the damn
business of HHH.
 

No, since the definition of NON-HALTING is that it will never stop after being emulated for an unbounded number of steps.
Once we fix DDD to be a program so we can use that definition, it is clear that any DDD based on, and was given to, an HHH that aborts and returns 0, will eventually halt, just after that HHH gave up and aborted.
Thus, by the REAL definition, it is HALTING.
Your use of LYING DEFINITIONS just shows that you are just a LIAR.
You have no excuse for claiming otherwise, as the proper defintions have been presented to you, and no rebuttal of those presented by you, so that *ARE* the definition in force, which you commit LYING by recklessly ignoring.