Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory
Subject: Re: Simulation vs. Execution in the Halting Problem
Date: Tue, 3 Jun 2025 22:17:39 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <b90b8c16be81769568781f8c181f145b2062a07b@i2pn2.org>
References: <yU0_P.1529838$4AM6.776697@fx17.ams4>
 <101a7uv$3vfam$5@dont-email.me> <101br7m$db03$1@dont-email.me>
 <101cjk7$hfof$7@dont-email.me>
 <d8d7c46fe2728e5481a504e6edacc8fd0fea5285@i2pn2.org>
 <101e8ak$vhu7$1@dont-email.me> <101etan$14dr4$2@dont-email.me>
 <101fbth$173bb$13@dont-email.me> <101fcgj$19e5f$2@dont-email.me>
 <101fia9$1cj4h$1@dont-email.me> <101fl5a$1dfmq$1@dont-email.me>
 <101fvok$1gaq8$1@dont-email.me> <101g68s$1i7tb$1@dont-email.me>
 <101g7ph$1iik6$1@dont-email.me> <101gaht$1j464$1@dont-email.me>
 <101ghl0$1p48p$1@dont-email.me> <101gjb3$1p7o2$1@dont-email.me>
 <101hsdt$2806l$1@dont-email.me> <101lodi$3pbm3$1@dont-email.me>
 <101m0tc$3qnt1$2@dont-email.me>
 <8f40254a281b3c8bdde179cd373ee894f6c210b4@i2pn2.org>
 <101nkn6$7qau$8@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 4 Jun 2025 02:35:24 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3190762"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <101nkn6$7qau$8@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 6/3/25 4:08 PM, olcott wrote:
> On 6/3/2025 6:14 AM, Richard Damon wrote:
>> On 6/3/25 1:23 AM, olcott wrote:
>>> 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 
========== REMAINDER OF ARTICLE TRUNCATED ==========