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 07:14:52 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <8f40254a281b3c8bdde179cd373ee894f6c210b4@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 3 Jun 2025 11:15:18 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="3097332"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
In-Reply-To: <101m0tc$3qnt1$2@dont-email.me>
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0

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 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. 
========== REMAINDER OF ARTICLE TRUNCATED ==========