Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: joes <noreply@example.org>
Newsgroups: comp.theory
Subject: Re: Defining a correct halt decider
Date: Tue, 3 Sep 2024 18:53:18 -0000 (UTC)
Organization: i2pn2 (i2pn.org)
Message-ID: <bcef318ec77a8792164a6626ba6d8a05007311da@i2pn2.org>
References: <vb4npj$1kg8k$1@dont-email.me> <vb6i8p$39fhi$1@dont-email.me>
	<vb72a4$3b4ub$6@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 3 Sep 2024 18:53:18 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="739540"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="nS1KMHaUuWOnF/ukOJzx6Ssd8y16q9UPs1GZ+I3D0CM";
User-Agent: Pan/0.145 (Duplicitous mercenary valetism; d7e168a
 git.gnome.org/pan2)
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 3542
Lines: 55

Am Tue, 03 Sep 2024 08:17:56 -0500 schrieb olcott:
> On 9/3/2024 3:44 AM, Mikko wrote:
>> On 2024-09-02 16:06:11 +0000, olcott said:
>> 
>>> A correct halt decider is a Turing machine T with one accept state and
>>> one reject state such that:
>>> If T is executed with initial tape contents equal to an encoding of
>>> Turing machine X and its initial tape contents Y, and execution of a
>>> real machine X with initial tape contents Y eventually halts, the
>>> execution of T eventually ends up in the accept state and then stops.
>>> If T is executed with initial tape contents equal to an encoding of
>>> Turing machine X and its initial tape contents Y, and execution of a
>>> real machine X with initial tape contents Y does not eventually halt,
>>> the execution of T eventually ends up in the reject state and then
>>> stops.
>> Your "definition" fails to specify "encoding". There is no standard
>> encoding of Turing machines and tape contents.
>> 
> That is why I made the isomorphic x86utm system.
> By failing to have such a concrete system all kinds of false assumptions
> cannot be refuted.
What would those assumptions be?

> The behavior of DDD emulated by HHH** <is> different than the behavior
> of the directly executed DDD** **according to the semantics of the x86
> language
How can the same code have different semantics?

> HHH is required to report on the behavior tat its finite string input
> specifies even when this requires HHH to emulate itself emulating DDD.
The input specifies an aborting HHH - which you don’t simulate.

> DDD never halts unless it reaches its own final halt state. The fact
> that the executed HHH halts has nothing to do with this.
Other than that DDD calls HHH?

> HHH is not allowed to report on the computation that itself is contained
> within.
Then it is only partial, and doesn’t even solve the case it was built for.

> Except for the case of pathological self-reference the behavior of the
> directly executed machine M is always the same as the correctly
> simulated finite string ⟨M⟩.
That sure sounds like a mistake to me.

> That no one has noticed that they can differ does not create an axiom
> where they are not allowed to differ.
They were never allowed, that was the definition.

> No one noticed that they differ only because everyone rejected the idea
> of a simulating halt decider out-of-hand without review.
I think after 3 years that excuse has grown a bit stale.

-- 
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.