Re: Defining a correct halt decider

Liste des GroupesRevenir à c theory 
Sujet : Re: Defining a correct halt decider
De : polcott333 (at) *nospam* gmail.com (olcott)
Groupes : comp.theory
Date : 07. Sep 2024, 15:35:13
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vbhob2$1ddlj$1@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 9/7/2024 5:31 AM, Fred. Zwarts wrote:
Op 06.sep.2024 om 13:41 schreef olcott:
On 9/6/2024 6:12 AM, Mikko wrote:
On 2024-09-05 13:39:14 +0000, olcott said:
>
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.
>
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.
>
Once I prove my point as the x86 level I show how the
same thing applies to the Peter Linz proof.
>
Your recent presentations are so far from Linz' proof that they
look totally unrelated.
>
>
I must begin where people are so far no one even understands
the concept of recursive emulation.
>
_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov ebp,esp   ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add esp,+04
[00002182] 5d         pop ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
Show the details of how DDD emulated by HHH
reaches its own machine address 0000217f.
>
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)
then
00002172, 00002173, 00002175, 0000217a calls HHH(DDD)...
>
WHAT SHOULD THE NEXT STEPS BE?
>
 That has been told now several times. A correct simulation (as by HHH1, or the unmodified world class simulator)
What comes next in the above sequence?
Changing the question to answer a different question
is the despicable lie of the strawman deception.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer

Date Sujet#  Auteur
14 Jul 25 o 

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal