Re: This function proves that only the outermost HHH examines the execution trace

On 7/26/2024 2:46 PM, Mike Terry wrote:

On 26/07/2024 16:56, olcott wrote:

This is meant for Mike, Joes and Fred don't have the technical competence to understand it.
 Richard might be able to understand it yet the fact that he is
stuck in rebuttal mode makes any understanding that he may have
utterly useless.
 Mike: It seems that HHH has been a pure function of its inputs
and never has provided data downward to its slaves that corrupts
their halt status decision. They don't even make a halt status
decision thus cannot make a corrupted one.

 Well, the first two claims are literally untrue - outer HHH effectively uses the static mutable data to pass flags to the inner HHH that modify its behaviour.  The Root flag below is derived from the actual static data and causes inner HHH to totally skip its own abort logic!
 You seem to acknowledge this, but claim it does not matter for various reasons, because whatever mistakes you are making, what finally gets printed out is saying the right thing!
 

 If HHH gets the correct answer in an impure way then it only
counts that it gets it in an impure way if it is impossible
to get in a pure way. This makes it possible for HHH to get
this answer in a pure way:
 Message-ID: <rLmcnQQ3-N_tvH_4nZ2dnZfqnPGdnZ2d@brightview.co.uk>
On 3/1/2024 12:41 PM, Mike Terry wrote:
 >
 > Obviously a simulator has access to the internal state
 > (tape contents etc.) of the simulated machine. No problem there.
 

The problem with this attitude is that when you describe your ideas and present the printed output, you say that HHH is "simulating" DDD, and people know what simulating means, and everyone has expectations of what that implies.  You are happy to use those expectations when it goes along with what you want to claim, but try to conceal that those expectations are unjustified because what you are doing is not "proper simulation" as everybody would understand it.
 

 It does not have any effect on the simulation. It only gets
the non-halting results that we can all see is correct in an
impure way. Each instruction of DDD is emulated precisely
according to the semantics that it specifies.
 

You can't have it both ways.
 

 It may seem that way if you are not paying close enough attention
or have insufficient skill with the semantics of the x86 language.
 

The way to avoid all such concerns is to implement simulation correctly, like you claim to have done.  Simulation is not /just/ the step by step simulation provided by libx86emu(sp?) -

 Yes it is. That *is* what simulation is.
The only thing that is added to this is termination analysis that
can be verified as correct even if this correct result was not
derived in a pure way.
 

your entire computation environment needs to correctly work together so that the end-to-end effect is that simulated code exactly follows the behaviour of the original code, at least up to the point where the simulator aborts.

 It has done that for three years and you never bothered to pay
enough attention to notice that it has done that for three years.
 

Put differently, you also need to simulate the /correct/ instructions and data.
 

 The instructions *are* the data.  A sequence of these instructions
(execution trace) is all that the termination analyzer uses.
 

The same applies to when you try to "copy" code,

 I don't try to copy code. libx86emu gets confused with
copied code.
 

as in your H1 and HHH1:  by definition of "copy" [as understood by everybody here] the behaviour of the copied code must exactly match that of the original code - otherwise it is simply not a proper "copy" by definition.
 

 There is no copy. It is always the exact same integer
machine address of DDD.
 Why do you insist on saying the the emulation of DDD by HHH
is incorrect when it is an easily verified fact that HHH
emulates each instruction of DDD exactly according to the
semantics specified by this instruction.
 Every time that anyone every said that the simulation was
incorrect I dared them to point to the line of code that
was simulated incorrectly and they responded with rhetoric,
ad hominem, and double talk and never pointed out any
instruction that was emulated incorrectly.
 These tactics may seem convincing to gullible fools yet are
as obvious as a pie-in-the-face to those having enormously
much more single-minded focus of attention.
 

As a joke alternative you could stop claiming to simulate or copy anything, and say instead you are misulating and pocying code!  You could say "HHH misulates DDD and sees that DDD will never halt" but obviously people will just say "What's misulating, and why should misulating (whatever it is) allow HHH to see things about DDD?"  You see - from your perspective that would be hopeless for your wider scope argument which attempts to invalidate the Linz/Sipser proofs.  Similarly if you claim that you "pocyed" HHH to HHH1 and they have different results when given input DDD, people will just look blank - what's "pocying" and why would anyone expect a pocyed routine to give the same result as the original routine?
 No, none of that flies.  It was a joke, but with a sensible aim - to convince you that for your wider scale arguments you need simulating (and copying) to have their correct meanings as everybody here will understand them.  No good saying "they mean something else, but it doesn't matter because what my program finally writes out is TRUE".
 Of course none of that will convince you of anything and you'll just continue.
 

 I could change the code so that the slave instances can and do
try to form a halt status decision on the basis of the execution
trace that they do have.

Your concept of master/slaves simulators is broken.  There are outer/inner simulators but that is just a relative term, and all simulated code (at whatever level) needs to have the same behaviour as the unsimulated code.
 If your simulation was correctly designed/implemented this would just work.  (Of course, HHH has to correctly use the DebugStep() (et al.) primitive ops to gather what it needs to make its decision, no cheating with globals etc..)
 

 That you disagree that the simulation is correct without being
able to point out a single line-of-code of DDD that was simulated
incorrectly seems to indicate that you are happy to directly
contradict verified facts.
 

I know you've said you don't have time to think about how to do this correctly.  That's fair enough, but in the meantime you should not claim that your incorrect implementation proves your conclusions!

 Anyone having sufficient knowledge of the x86 language can verify
the only two relevant details:
 DDD is correctly emulated by HHH until it correctly determines
that DDD specifies not halting behavior that must be aborted.
 

 To be fair, you shouldn't need x86utm.exe in your arguments - it is not the Appeal To Authority that you imagine it to be!  All of your arguments could just be phrased in pseudo-code and there would not be any disagreement about how that would behave by posters here.  Of course, your ideas expressed that way would still be Wrong, and nobody would agree with them, but that's the case anyway when you try to bring in x86utm!
 

 That you disagree that the simulation is correct without being
able to point out a single line-of-code of DDD that was simulated
incorrectly seems to indicate that you are happy to directly
contradict verified facts.