Re: Defining a correct halt decider

Liste des GroupesRevenir à theory 
Sujet : Re: Defining a correct halt decider
De : richard (at) *nospam* damon-family.org (Richard Damon)
Groupes : comp.theory
Date : 06. Sep 2024, 03:35:02
Autres entêtes
Organisation : i2pn2 (i2pn.org)
Message-ID : <4ac5a1400ece16308c8a19f100e77312b598c3b1@i2pn2.org>
References : 1 2 3 4 5
User-Agent : Mozilla Thunderbird
On 9/5/24 9:39 AM, olcott wrote:
On 9/5/2024 2:39 AM, Mikko wrote:
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.
 They do yet I cannot provide every single details of
the source-code of the Turing machine because these
details would be too overwhelming.
No, the CAN NOT be, as a Turing Machine can not have as its input part of itself.
It can have a copy of its description given to it, but not a piece of itself.
This allows you in your x86 code to do something the Turing Machine can not do, and that is compare the "addresss" in the input to itself to detect the "self-reference".
Sorry, you just don't know what you are talking about and prove you are just a lying idiot.

 So instead every author makes a false assumption that
is simply believed to be true with no sufficient basis
to show that it isn't true.
Nope, you just prove that you don't know what you are talking about.

 Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
Nope, first, because you HHH is NOT a "Computation" because it isn't a pure function, but uses static memory to relay information (BOTH WAYS) and change behavior.
Second, Because of your non-equivalence, you were able to do something proved impossible for actual independent computations, and that is to accurately detect that the input is using a "copy" of itself.

 
>
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.
 Is is about the behavior that this string specifies.
Which is the behavior of the program it represents, and thus needs to include ALL the code referenced.

 HHH computes the mapping from its input finite string
to the behavior that this finite string specifies on
the basis of DDD emulated by HHH.
But does it incorrectly, because it never completes it.

 DDD emulated by HHH cannot possibly reach its final halt
state and on this basis alone HHH is correct to reject
DDD and report non-halting.
 
But it does, as you have been told.
You just keep on confusing the behavior of DDD with the behavior of the partial emulation of DDD by HHH. They are diffferent, and thus it is an error to confuse them.

When there is a pathological relationship to the decider
and its input then this behavior must include DDD calling
HHH to emulated itself again.
Right, which HHH fails to do. HHH must make its decision based on the fact that the call to HHH in DDD will do exactly what this HHH decides to do.
If this HHH aborts and return, then it must be able to show that if the HHH that it is simulating does the same thing, then its answer is correct.
You are just proving you don't know what you are talking about.

 That no one bothered to notice that the behavior of an
input DDD to a simulating termination analyzer HHH can
be different than the behavior of a directly executed
DDD when there is a pathological relationship between
HHH and DDD IS NOT MY MISTAKE.
But it can't and you have accepted that by failing to show the first instruction actually correctly emulated by HHH that differed in behavior.
Sorry, you are just proving yourself to be a stupid liar.

 
Your decider is not a halt decider if it answers about another
behaviour.
>
 

Date Sujet#  Auteur
2 Sep 24 * Defining a correct halt decider41olcott
2 Sep 24 +- Re: Defining a correct halt decider1Richard Damon
3 Sep 24 `* Re: Defining a correct halt decider39Mikko
3 Sep 24  `* Re: Defining a correct halt decider38olcott
3 Sep 24   +* Re: Defining a correct halt decider10joes
3 Sep 24   i`* Re: Defining a correct halt decider9olcott
4 Sep 24   i +- Re: Defining a correct halt decider1Richard Damon
4 Sep 24   i +- Re: Defining a correct halt decider1joes
4 Sep 24   i +* Re: Defining a correct halt decider5Fred. Zwarts
4 Sep 24   i i`* Re: Defining a correct halt decider4olcott
5 Sep 24   i i +- Re: Defining a correct halt decider1Richard Damon
5 Sep 24   i i +- Re: Defining a correct halt decider1Richard Damon
5 Sep 24   i i `- Re: Defining a correct halt decider1Fred. Zwarts
12 Sep 24   i `- Re: Defining a correct halt decider1immibis
4 Sep 24   +- Re: Defining a correct halt decider1Richard Damon
4 Sep 24   +* Re: Defining a correct halt decider5Fred. Zwarts
4 Sep 24   i+* Re: Defining a correct halt decider3olcott
5 Sep 24   ii+- Re: Defining a correct halt decider1Richard Damon
5 Sep 24   ii`- Re: Defining a correct halt decider1Fred. Zwarts
6 Sep 24   i`- Re: Defining a correct halt decider1Mikko
5 Sep 24   `* Re: Defining a correct halt decider21Mikko
5 Sep 24    `* Re: Defining a correct halt decider20olcott
5 Sep 24     +* Re: Defining a correct halt decider4joes
5 Sep 24     i`* Re: Defining a correct halt decider3olcott
6 Sep 24     i +- Re: Defining a correct halt decider1Richard Damon
6 Sep 24     i `- Re: Defining a correct halt decider1Fred. Zwarts
6 Sep 24     +- Re: Defining a correct halt decider1Richard Damon
6 Sep 24     `* Re: Defining a correct halt decider14Mikko
6 Sep 24      `* Re: Defining a correct halt decider13olcott
7 Sep 24       +- Re: Defining a correct halt decider1Richard Damon
7 Sep 24       +* Re: Defining a correct halt decider7Mikko
7 Sep 24       i`* Re: Defining a correct halt decider6olcott
8 Sep 24       i +* Re: Defining a correct halt decider4Mikko
8 Sep 24       i i`* Re: Defining a correct halt decider3olcott
8 Sep 24       i i +- Re: Defining a correct halt decider1Mikko
8 Sep 24       i i `- Re: Defining a correct halt decider1Richard Damon
8 Sep 24       i `- Re: Defining a correct halt decider1Fred. Zwarts
7 Sep 24       `* Re: Defining a correct halt decider4Fred. Zwarts
7 Sep 24        `* Re: Defining a correct halt decider3olcott
7 Sep 24         +- Re: Defining a correct halt decider1Richard Damon
8 Sep 24         `- Re: Defining a correct halt decider1Fred. Zwarts

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal