Path: ...!news.misty.com!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: Defining a correct simulating halt decider
Date: Mon, 2 Sep 2024 12:50:39 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <3ba157af9a08402c2bc439e90fa43b983fbea7bb@i2pn2.org>
References: <vb4plc$2tqeg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 2 Sep 2024 16:50:39 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="602294"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
In-Reply-To: <vb4plc$2tqeg$1@dont-email.me>
Content-Language: en-US
Bytes: 3433
Lines: 68

On 9/2/24 12:38 PM, olcott wrote:
> A halt decider is a Turing machine that computes
> the mapping from its finite string input to the
> behavior that this finite string specifies.
> 

Where the "finite string" is a representation of a Turing Machine and 
its input, and the mapping is the behavior of that Machine/Input when run.

Important point, as only a Machine and its input has the "halting" 
property, and its is the direct


> If the finite string machine string machine
> description specifies that it cannot possibly
> reach its own final halt state then this machine
> description specifies non-halting behavior.


Which MEANS the direct execution of the machine and input the finite 
string describes.


> 
> A halt decider never ever computes the mapping
> for the computation that itself is contained within.

But it can be asked about a computation that includes a copy of itself.

Of course, the decider is looking at an input that might create another 
instance of itself by using a copy of itself, and that is a valid question.

It is of course structurally impossible for an input to include *THIS* 
instance of the decider as the input doesn't specify what "instance" it 
is of, just the code, and the instance is created when it is run/simulated.

> 
> Unless there is a pathological relationship between
> the halt decider H and its input D the direct execution
> of this input D will always have identical behavior to
> D correctly simulated by simulating halt decider H.

No, the "pathological relationship" doesn't affect the meaning of the 
input or the question being asked.

The question is SPECIFICALLY about the behavior of the machine and input 
described to the decider, and NOT about what the decider can determine 
about the input.

Sorry, you are just proving that you are nothing but an ignorant liar.



> 
> *Simulating Termination Analyzer H Not Fooled by Pathological Input D*
> https://www.researchgate.net/publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
> 
> A correct emulation of DDD by HHH only requires that HHH
> emulate the instructions of DDD** including when DDD calls
> HHH in recursive emulation such that HHH emulates itself
> emulating DDD.
> 
> ** According to the semantics of the x86 language.
> 
> 
> 

Which just LIES about what it is trying to show, because you don't 
understand the problem you say you are working on.