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: Thu, 29 May 2025 19:35:30 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <da9b740302fe50f0601cf1713c1775d17a62ba48@i2pn2.org>
References: <yU0_P.1529838$4AM6.776697@fx17.ams4>
 <101a7uv$3vfam$5@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 29 May 2025 23:49:39 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2483672"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <101a7uv$3vfam$5@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4194
Lines: 83

On 5/29/25 2:10 PM, olcott wrote:
> 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.
> 

No, the DEFINITION of "the behavior of the input" is EXACTLY the 
behavior of the direct execution of the program the input represents.

There is not "call the simulator" exception. If you want to claim one, 
show the reference, or you are just admitting that you whole proof is 
based on made up lies.

The behavior REVEALED will be incomplete if the simulation is 
incomplete, but the defined behavior of the input is still as defined.

>> ✅ What’s True:
>> Running a simulation of a program—even partially—is meant to reflect its
>> execution behavior.
>> Simulators, emulators, or analyzers aim to predict how a program would
>> behave if actually run.
>>
>> ⚠️ Where the Divergence Happens:
>>
>> 1. Simulation May Not Be Complete
>> Even if the simulator detects what it believes to be infinite recursion,
>> it:
>> - Has not observed it to infinity
>> - Has inferred it based on structure or partial behavior
>>
>> 2. Execution Is Definitive, Simulation Is Predictive
>> - Execution is actual: the program runs on hardware (real or virtual) and
>> either halts or doesn’t.
>> - Simulation is analytic: a model tries to deduce the result without 
>> fully
>> committing to it.
>>
>> 🔄 What SHDs Claim (Flibble/Olcott):
>> If the SHD halts its simulation due to detecting a provable infinite
>> recursion, then that should be considered a correct determination of non-
>> halting for the input program.
>>
>> This leads to their argument:
>> - SHD's halting ≠ the program’s halting
>> - But SHD's halting due to detection of infinite recursion ⇒ program’s
>> non-halting
>>
>> 🧩 The Problem:
>> In classical computability theory:
>> - You can’t always know that a structure will cause non-halting.
>> - Many programs appear recursive but halt (e.g., bounded recursion).
>> - There’s no general algorithm that can always correctly detect infinite
>> recursion in all programs.
>>
>> Thus:
>> Simulation that halts does not conclusively determine that the simulated
>> program would or would not halt — unless the simulation is exhaustive and
>> faithful, which isn't always possible.
>>
>> ✅ Conclusion:
>> Partial simulation provides strong hints but not definitive proof of
>> halting or non-halting — unless the analysis itself is provably sound and
>> complete within a restricted system (e.g., total languages).
> 
> HHH never rejects any input unless it has proven:
> *would never stop running unless aborted*
> 
> 

Nope, but then you have admitted that your application of the problem is 
based on starting with a category error and neither your decider or the 
input are as required, but just lies.