Re: Simulation vs. Execution in the Halting Problem

On 6/1/2025 10:42 AM, Mike Terry wrote:

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

On 5/31/2025 10:32 PM, Mike Terry wrote:

On 01/06/2025 02:31, olcott wrote:

On 5/31/2025 7:44 PM, Mike Terry wrote:

On 01/06/2025 01:18, olcott wrote:

[..snip..]

>
We cannot do a separate side-by-side execution trace of
HHH(DDD) and HHH1(DDD) because the DDD simulated by HHH1
calls HHH(DDD) as a part of this same simulation.

>
Duh!  The DDD simulated by HHH ALSO calls HHH(DDD) as a part of the same simulation.
>
They BOTH call HHH(DDD) as part of the simulation.  Duuuuuh....
>
I've presented the two traces to you side by side on more than one occasion.  Do you really have no recollection of that?  Your explanation of why we supposedly can't put them side by side is literally gibberish!
>

>
 From the trace shown below we can see that HHH simulates
DDD one whole execution trace more than HHH1 does.

>
Really?  That's not at all what I see - but perhaps you can explain what you're saying.
>
Mark on the trace below where you think HHH1's simulation [i.e. the simulation /performed/ by HHH1] starts and ends.  Also mark where you think HHH's simulation starts and ends.
>
Then to save me the trouble, try to put them side by side to see if they match up...
>
>
Mike.
>

>
I really appreciate your sincere honesty and the great
diligence that you have shown evaluating my work. No
one else on the planet has put nearly the same effort
as you in carefully evaluating the key details of my work.
>

 There is a terminology issue here to resolve.
 If A simulates B and B simulates C, what should a "trace" of A's simulation look like?
a)   it includes both B's and C's instructions, interlaced.
b)   it is just B's instructions.
 

HHH1(DDD) simulates one instance of DDD.
HHH(DDD) simulates DDD and simulates itself simulating DDD
and then aborts after it has already simulated DDD one more
time than HHH1 ever does.

Both of those would be valid ways of looking at things.
 (a) is more in line with how you typically present traces, and in your

I merely show that actual trace that is actually produced
during the actual execution of HHH1(DDD).

code A's view of the simulations includes both B's and C's instructions - it needs to be that way for your so-called "infinite recursive emulation" test to make sense.
 (b) is ok too, as long as consistency is maintained.
 

It is too confusing for me to refer to this as anything besides
the actual names.

The claim you are disputing is "HHH1's and HHH's simulation of DDD exactly match up to the point where HHH aborts".

That is wrong. They exactly match up until HHH begins
to simulate itself simulating DDD. The abort is much later.

More generally, any two (partial) simulations of any program will match, up to the earliest step where one of the simulations is aborted.

Factually incorrect.
You keep ignoring that DDD calls HHH(DDD) in recursive
simulation and DDD *does not* call HHH1(DDD) in recursive simulation.

 Definition (b) is "weaker" than (a), in that if (a) is understood, and the two simulations match under this definition, then it is obvious that under definition (b) the simulations will still match, because (b) is just some filtered version of (a).
 So I'll pause here until you say which of (a) (b) you think characterises simulations matching or not matching.
  Mike.
 

I can't deal with (a) and (b) it makes the analysis
too complicated to be done reliably. All analysis
must be made as simple as possible, just like all
code must be made as simple as possible to eliminate
accidental complexity
https://en.wikipedia.org/wiki/No_Silver_Bullet
Taking the Mythical Man Month to heart increases
the quality of software development ten-fold.
Make everything as simple and self-explanatory as possible.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer