Re: Simulation vs. Execution in the Halting Problem

On 6/2/2025 9:58 PM, Mike Terry wrote:

On 01/06/2025 16:42, 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.
>
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 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.
>
The claim you are disputing is "HHH1's and HHH's simulation of DDD exactly match up to the point where HHH aborts".  More generally, any two (partial) simulations of any program will match, up to the earliest step where one of the simulations is aborted.  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.
>

 PO's response elsewhere is to not engage in clarification, but instead just repeat over and over his intuition that the simulations of DDD performed by HHH1 and HHH are /substantially/ different, rather than differing just in how long each simulates before aborting.
 Each intuition PO puts forward is seen to be /idiotically/ false, simply by looking at the traces that PO himself has supplied!  So this situation is like PO claiming HHH is correct to decide non-halting for DDD, despite his own traces showing that DDD halts.  In both cases PO shows a total misunderstanding of basic concepts [halting/simulation respectively], and show that his delusions are quite robust when it comes to challenges based on logical reasoning.  Even if presented with /direct observations/ contradicting his position, PO can (will) just invent new magical thinking that only he is smart enough to understand, in order to somehow justify his busted intuitions.
 So posters hoping to change PO's mind take note:  you are utterly wasting your time if that is your objective!  Also posters thinking its their /duty/ to keep the internet pure for the protection of young children who might one day read PO's posts and be misled, possibly leading to them failing their exams then in despair turning to drugs and a life of crime - hehe, you know that's just a post-hoc excuse for your posting.  Not that there's anything inherently bad about highlighting PO's mistakes, it's just that it's not /required/ and when it gets out of control it will consume /vast/ amounts of posters time.
    <https://xkcd.com/386>
 Of course, posters should post while they're having fun, but...  nothing new has been said for years, and people are posting the same responses over and over and over and over and over...  At some point, surely that just becomes /boring/, surely.
 ----------------
Anyhow, for the record here are the side by side comparisons of PO's HHH1's and HHH's simulations of DDD, using PO's own traces:
      HHH1 Simulation of DD (HHH1 never aborts)          HHH Simulation of DD
==========================================        ==========================================
  S  machine   machine        assembly              S  machine   machine        assembly
  D  address   code           language              D  address   code           language
  =  ========  ============== =============         =  ========  ============== =============
### HHH1 simulates DDD                            ### HHH simulates DDD
[1][00002183] 55         push ebp                 [1][00002183] 55         push ebp
[1][00002184] 8bec       mov ebp,esp              [1][00002184] 8bec       mov ebp,esp
[1][00002186] 6883210000 push 00002183 ; DDD      [1][00002186] 6883210000 push 00002183 ; DDD
[1][0000218b] e833f4ffff call 000015c3 ; HHH      [1][0000218b] e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD...                          ### HHH simulates DDD...
[2][00002183] 55         push ebp                 [2][00002183] 55         push ebp
[2][00002184] 8bec       mov ebp,esp              [2][00002184] 8bec       mov ebp,esp
[2][00002186] 6883210000 push 00002183 ; DDD      [2][00002186] 6883210000 push 00002183 ; DDD
[2][0000218b] e833f4ffff call 000015c3 ; HHH      [2][0000218b] e833f4ffff call 000015c3 ; HHH
### HHH simulates DDD...                          ### OUTER HHH aborts
[3][00002183] 55         push ebp
[3][00002184] 8bec       mov ebp,esp
[3][00002186] 6883210000 push 00002183 ; DDD
[3][0000218b] e833f4ffff call 000015c3 ; HHH
### HHH[1] aborts
### DDD[1] returns
[1][00002190] 83c404     add esp,+04
[1][00002193] 5d         pop ebp
[1][00002194] c3         ret
 [SD column is simulation depth]
 These traces are merges of the instructions from all simulation levels, and are filtered to just show DDD instructions, as that's what PO normally presents.  Traces match up to the point where (outer) HHH aborts.
 If we showed HHH instructions and subroutines, we would find mismatches that are caused by PO's misuse of mutable static data, i.e. his broken simulation implementation.  Once those are fixed, the two traces exactly match up again [but we are talking hundreds of pages, so it is not that useful, beyond confirming that the (fixed) simulation is working properly].
  Mike.
 

How many times does HHH1(DDD) simulate itself simulating DDD?
How many times does HHH(DDD) simulate itself simulating DDD?
*Saying that you don't think it makes a difference dodges the question*
void DDD()
{
   HHH(DDD);
   return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
*Every rebuttal to this changes the words*
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer