Re: Simulation vs. Execution in the Halting Problem

On 6/1/25 11:28 PM, olcott wrote:

On 6/1/2025 8:15 PM, Richard Damon wrote:

On 6/1/25 12:23 PM, olcott wrote:

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.
>
>

>
The problem isn't that it makes the analysis too complicated, it makes your errors clear.
>

 It is simpler to keep the existing names of HHH and HHH1
instead of translating back and forth between these names
and Mike's new names of (a) and (b).

That wasn't his differencre.

 (1) HHH simulates DDD and then simulates itself simulating DDD.

And thus simulates DDD and then HHH simulating DDD
by resolving "itself" to what it means. After all, the meaning of the input isn't based on who it is given to, but on what it means, as inputs are to be internally self-contained.
Thus HHH must be defined in the input, or a constant in the system, either way, it refers to the SPECIFIC code of the HHH that you started with.

(2) HHH1 never ever simulates itself.

But it simulates DDD and then simulates HHH simulating DDD

These two are not the same.

Yes they are, at least in the domain of PROGRAMS.
Both HHH and HHH1 simulate DDD calling HHH which then simulates DDD

 As soon as HHH simulates the very first instruction of
itself the simulation of DDD by HHH1 and the simulation
of DDD by HHH diverges.

How? The first instructio of HHH is the same whether it is simulated by HHH or by HHH1
I guess you are just showing that you world is based on the right to lie about what actually is by using equivocation.

 

OVER simplification to the point of being in error, is just the tool of the liar, which shows what you are.