Liste des Groupes | Revenir à theory |
On 9/5/2024 2:39 AM, Mikko wrote:No, the CAN NOT be, as a Turing Machine can not have as its input part of itself.On 2024-09-03 13:17:56 +0000, olcott said:They do yet I cannot provide every single details of
>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 source-code of the Turing machine because these
details would be too overwhelming.
So instead every author makes a false assumption thatNope, you just prove that you don't know what you are talking about.
is simply believed to be true with no sufficient basis
to show that it isn't true.
Once I prove my point as the x86 level I show how theNope, 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.
same thing applies to the Peter Linz proof.
Which is the behavior of the program it represents, and thus needs to include ALL the code referenced.>Is is about the behavior that this string specifies.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.
HHH computes the mapping from its input finite stringBut does it incorrectly, because it never completes it.
to the behavior that this finite string specifies on
the basis of DDD emulated by HHH.
DDD emulated by HHH cannot possibly reach its final haltBut it does, as you have been told.
state and on this basis alone HHH is correct to reject
DDD and report non-halting.
When there is a pathological relationship to the deciderRight, 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.
and its input then this behavior must include DDD calling
HHH to emulated itself again.
That no one bothered to notice that the behavior of anBut it can't and you have accepted that by failing to show the first instruction actually correctly emulated by HHH that differed in behavior.
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.
Your decider is not a halt decider if it answers about another
behaviour.
>
Les messages affichés proviennent d'usenet.