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: Fri, 30 May 2025 21:16:39 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <d8d7c46fe2728e5481a504e6edacc8fd0fea5285@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 31 May 2025 01:27:34 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2626636"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <101cjk7$hfof$7@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

On 5/30/25 11:41 AM, olcott wrote:
> On 5/30/2025 3:45 AM, Mikko wrote:
>> On 2025-05-29 18:10:39 +0000, olcott said:
>>
>>> On 5/29/2025 12:34 PM, Mr Flibble wrote:
>>>>
>>>> 🧠 Simulation vs. Execution in the Halting Problem
>>>>
>>>> In the classical framework of computation theory (Turing machines),
>>>> simulation is not equivalent to execution, though they can 
>>>> approximate one
>>>> another.
>>>
>>> To the best of my knowledge a simulated input
>>> always has the exact same behavior as the directly
>>> executed input unless this simulated input calls
>>> its own simulator.
>>
>> The simulation of the behaviour should be equivalent to the real
>> behaviour. 
> 
> That is the same as saying a function with infinite
> recursion must have the same behavior as a function
> without infinite recursion.

Nope. Where does it say that?

Your problem is you don't understand that the only things you can 
correctly simulate are PROGRAMS, which mean they include all of their 
code, which is also expressed in the input given to the simulator.

> 
>> Whether it actually is depends on the quality of the
>> simulator. There is no exception for the case when the simulator
>> is called. If the behaviour in the simulation is different from
>> a real execution then the simulation is wrong.
>>
> 
> A function that calls its own simulator specifies different
> behavior than a function that does not call its own simulator.

No it doesn't, as we can only be talking about programs, and programs 
don't know who "their simulator" is, only what simulator they were built 
to use.

> 
>> One of the advantages of Turing machines is that there is no possibility
>> to call anything so the effect of calling the simulator need not be
>> considered.
>>
> 
> The same issue occurs in the Linz proof, it is merely more
> difficult to see. The correctly simulated ⟨Ĥ⟩ ⟨Ĥ⟩ cannot
> possibly reach its own simulated final halt state ⟨Ĥ.qn⟩

What "Issue"? Your problme is you don't understand what you are taling 
about.

> 
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Why did the copy of H change to being called "embedded_H"?

> 
> (a) Ĥ copies its input ⟨Ĥ⟩
> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
> (g) goto (d) with one more level of simulation
> 

Which then gets stop when the embedded_H invoked at the first invocation 
of (b) doing step (c) decides to abort its emulation.

Of courese, if it never does, then H can nover do it either (since they 
are DEFINED to be the exact same algorithm) and thus H failea to be a 
decider.

You are just showing that your "logic" is based on LYING about what you 
are doing, and that you are too stupid to understand the requirements, 
and you don't care to learn them (or are just mentally incapable).