Path: ...!weretis.net!feeder9.news.weretis.net!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: Mon, 2 Jun 2025 07:10:29 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <0019d1f2e59d851fba1f594bc2e594dcc97ad389@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> <101hup8$28mot$1@dont-email.me>
 <7b5072c5b71fcf0efd26dfa22b62db1d597369a7@i2pn2.org>
 <101j5oh$2urhr$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 2 Jun 2025 11:21:20 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2951518"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <101j5oh$2urhr$2@dont-email.me>
Bytes: 7828
Lines: 166

On 6/1/25 11:28 PM, olcott wrote:
> On 6/1/2025 8:15 PM, Richard Damon wrote:
>> On 6/1/25 12:23 PM, olcott wrote:
>>> On 6/1/2025 10:42 AM, 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.
>>>>
>>>
>>> HHH1(DDD) simulates one instance of DDD.
>>> 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.
>>>
>>>> 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 
>>>
>>> I merely show that actual trace that is actually produced
>>> 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.
>>>>
>>>> (b) is ok too, as long as consistency is maintained.
>>>>
>>>
>>> It is too confusing for me to refer to this as anything besides
>>> the actual names.
>>>
>>>> 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.
>>>
>>>> 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 recursive
>>> simulation and DDD *does not* call HHH1(DDD) in recursive simulation.
>>>
>>>>  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.
>>>
>>>
>>
>> The problem isn't that it makes the analysis too complicated, it makes 
>> your errors clear.
>>
> 
> It is simpler to keep the existing names of HHH and HHH1
> instead of translating back and forth between these names
> and Mike's new names of (a) and (b).

That wasn't his differencre.

> 
> (1) HHH simulates DDD and then simulates itself simulating DDD.

And thus simulates DDD and then HHH simulating DDD

by resolving "itself" to what it means. After all, the meaning of the 
input isn't based on who it is given to, but on what it means, as inputs 
are to be internally self-contained.

Thus HHH must be defined in the input, or a constant in the system, 
either way, it refers to the SPECIFIC code of the HHH that you started with.

> (2) HHH1 never ever simulates itself.

But it simulates DDD and then simulates HHH simulating DDD


> These two are not the same.

Yes they are, at least in the domain of PROGRAMS.

Both HHH and HHH1 simulate DDD calling HHH which then simulates DDD

> 
> As soon as HHH simulates the very first instruction of
> itself the simulation of DDD by HHH1 and the simulation
> of DDD by HHH diverges.

How? The first instructio of HHH is the same whether it is simulated by 
HHH or by HHH1

I guess you are just showing that you world is based on the right to lie 
about what actually is by using equivocation.

> 
>> OVER simplification to the point of being in error, is just the tool 
>> of the liar, which shows what you are.
> 
> 
========== REMAINDER OF ARTICLE TRUNCATED ==========