Liste des Groupes | Revenir à theory |
On 6/1/2025 10:42 AM, Mike Terry wrote:Your response below basically says that you don't understand what "simulation" is.On 01/06/2025 05:01, olcott wrote:On 5/31/2025 10:32 PM, Mike Terry wrote:[..snip..]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:
HHH1(DDD) simulates one instance of DDD, then its nested simulations.HHH1(DDD) simulates one instance of DDD.>>>>
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.
>
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.
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.Both of those would be valid ways of looking at things.I merely show that actual trace that is actually produced
>
(a) is more in line with how you typically present traces, and in your
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.It is too confusing for me to refer to this as anything besides
>
(b) is ok too, as long as consistency is maintained.
>
the actual names.
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.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.
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.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 recursiveThat 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.
simulation and DDD *does not* call HHH1(DDD) in recursive simulation.
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.)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.
Les messages affichés proviennent d'usenet.