Re: Defining a correct halt decider

Liste des GroupesRevenir à c theory 
Sujet : Re: Defining a correct halt decider
De : mikko.levanto (at) *nospam* iki.fi (Mikko)
Groupes : comp.theory
Date : 05. Sep 2024, 08:39:41
Autres entêtes
Organisation : -
Message-ID : <vbbn7t$8ocm$1@dont-email.me>
References : 1 2 3
User-Agent : Unison/2.2
On 2024-09-03 13:17:56 +0000, olcott said:

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.
If it were isnomorphic the same false assumtipns would apply to both.

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
The halting problem is not about a string but about a behaviour.
Your decider is not a halt decider if it answers about another
behaviour.
--
Mikko

Date Sujet#  Auteur
4 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal