Re: Simulation vs. Execution in the Halting Problem

On 01/06/2025 17:23, 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..]

Your response below basically says that you don't understand what "simulation" is.
That's not at all surprising, but given this, you are in no position to make assertions about whether two simulations are the same or not, up to the point where one of them is aborted.
I'll probably go back up the thread to where I asked you questions, and just give the answers myself for the record.

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

HHH1(DDD) simulates one instance of DDD, then its nested simulations.
HHH(DDD) simulates one instance of DDD, then its nested simulations.
IT'S THE SAME, UP TO THE POINT WHERE DDD IS ABORTED, EXACTLY AS I CLAIMED.

 

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.

LOL.  Ok, I've seen this before from you - it's your way of admitting you don't understand what's going on.  In this case you don't understand "simulation".  It follows you don't have ANY criterion for judging whether HHH1's and HHH's simulation of DDD match up or not!  Anything you come up with on this is just "things you think", i.e. your intuitions, which are often faulty.

 

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.

It's not wrong.  You're just confused, but I can't be bothered explaining why!  The question could be resolved by comparing traces, but you refuse to go down that path.

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.

Dude - it is easily *PROVED*.  Simulation is just the calculation of the successive computation steps, and there is EXACTLY ONE WAY that any computation can go.  It is like a train on a single-track railway that runs from A to B.  If the train starts at A, it will always end up at B - it can't suddenly end up at C.  And it doesn't matter who manufactures the train - all trains go along the same track.  OK, we should modify this analogy slightly - a train might go a way along the track then choose to stop, which we could call an aborted journey.  The point is all the trains go along the same path.  We can say the train's make the same journey up to the point where they are aborted.
When beginner students go to "Computation Theory 101", they already know this much unofficially - they know at least that computations have a starting point, and then follow a definite set of concrete steps until the result is produced.  They know that at each step of the computation the result is totally defined by the input data and the computation rules.  Otherwise the whole course, including its name, would not make sense.
I'd go further and say that school children understand this - if you gave them two 4-digit numbers to multiply, they realise there is a right answer that they can get by following the long-multiplication rules they've been taught.  If you are reading out the answers in class while the children mark their answers, and tell them that the answer is 43991832 for children whose names start A-G, but 83892822 for everyone else, they will know this is WRONG; the answer does not depend on who calculates it.

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

That does not affect the simulations, so it is quite ok to ignore.  You often accuse people of ignoring things that are irrelevent, but you are the one who is clueless.  You have no way of countering logical reasoning presented by others, so you invent magical differences that "must be taken into account" and only you can see!  It's just nonsense.

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

Normally I would have snipped the following, as there's nothing useful to be said about it.  In this case I've left it to help others recognise the gibberish you come out with when you've recognised that you simply can't understand what's going on.  (It's a common pattern of yours.)
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.