Re: DDD emulated by HHH diverges from DDD emulated by HHH1--- BEST ONE

On 6/7/25 7:54 PM, olcott wrote:

On 6/7/2025 6:38 PM, Richard Damon wrote:

On 6/7/25 10:13 AM, olcott wrote:

On 6/7/2025 6:18 AM, Richard Damon wrote:

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

On 6/6/2025 9:02 PM, Richard Damon wrote:

On 6/6/25 12:53 PM, olcott wrote:

On 6/6/2025 11:06 AM, Mike Terry wrote:

On 05/06/2025 05:27, olcott wrote:

On 6/4/2025 10:55 PM, Mike Terry wrote:

On 05/06/2025 02:39, olcott wrote:

On 6/4/2025 8:28 PM, dbush wrote:

On 6/4/2025 9:08 PM, olcott wrote:

On 6/4/2025 7:41 PM, dbush wrote:

On 6/4/2025 8:32 PM, olcott wrote:

>
Show me this side-by-side trace and I will point out your mistake.

>
See below, which shows that the simulations performed by HHH and HHH1 are identical up to the point that HHH aborts, as you have agreed on the record.
>

>

>
False.  The correct trace is the one I posted, which shows all levels of emulation performed by HHH and HHH1.  See the corrections I made to your comments

>
It is not supposed to do that.

>
Are you saying it's not supposed to include /nested/ emulations? It is perfectly sensible to include nested emulations.
>

>
It can include nested simulations yet nested
simulations are in a hierarchy thus not side-by-side.
A side-by-side analysis must be side-by-side.
>

>
Hierarchies can be compared side-by-side.  In the case of these traces, the hierarchy can be "flattened" into one stream of nested simulations. You do this yourself every time you present one of your nested simulation traces.  Such a trace should include a simulation depth (or equivalent) for each entry.
>
Two nested simulation traces can easily be presented side-by- side for comparisson.  You are just trying to divert attention from your own failings to properly understand the requirements.
>

>
*From the execution trace of HHH1(DDD) shown below*
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
*HHH1 emulates DDD once then HHH emulates DDD once, these match*
>
*Then HHH emulates itself emulating DDD, HHH1 NEVER DOES THIS*

>
Because the correct emulation of the input doesn't call for this to be done, and the identity of the emulator doesn't affect the defintion of a correct emulation.
>
That fact that NONE of your traces actually show a correct emulation,

>
I have corrected you on this hundreds of times and
you keep "forgetting" what I said.
>
>

>
That you have an "excuse" doesn't change the fact that the traces shown are not correct.
>

>
*No actual error has ever been pointed out*
One of the incoherent notions of error that you
have proposed is that a non-terminating input
was not simulated to completion.

>
No, it just that you don't seem to understand the concept that a partial simulation not reaching a final state doesn't establish non- halting.
>

 *CAN'T POSSIBLY REACH A FINAL STATE DOES ESTABLISH NOT HALTING*
 

Right, but the subject of said proposition is the MACHINE, not a partial simulation of said machine.
For simulations to be used to show non-halting, you must show that even after an unbounded number of steps simulated, it never reaches a final state.
The finite number N steps that any of your HHH that reports non-halting does, is NOT a "Unbounded number", and thus your HHH is not a source of truth for that attribute.
Also, Halting (or Non-Halting) is only a property of PROGRAMS, something you admit that you DDD is not, so it is just a categorical error to talki about if your DDD halts or not.
Sorry, but you are just proving you stupidity.