Re: Defining a correct halt decider

Liste des GroupesRevenir à theory 
Sujet : Re: Defining a correct halt decider
De : F.Zwarts (at) *nospam* HetNet.nl (Fred. Zwarts)
Groupes : comp.theory
Date : 07. Sep 2024, 11:31:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vbha1v$1aru4$3@dont-email.me>
References : 1 2 3 4 5 6 7
User-Agent : Mozilla Thunderbird
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) show that the next instruction is at 000015d2 (in HHH) and when HHH returns the next instruction in DDD is 0000217f, 00002182, 00002183 and DDD halts.
But, indeed, HHH fails to reach that part of the simulation, because it decided to stop the simulation too soon.
The problem is the code that tries to detect an infinite recursion. It fails to see that there are only two recursion for each HHH.
Olcott is still dreaming of a HHH that will not see this 'special condition'. He does not realise that by adding the code to recognize this 'special condition' and stop the simulation, the other HHH, that does not see this 'special condition', disappeared and remains only in his dreams. HHH, when simulating *itself* should now decide about the DDD that uses this new HHH that sees this 'special condition' and aborts.
*That code* is where the problem is, not the incomplete simulation itself.
In fact, if Olcott would have found a solution for the halting problem, then it would not be in the simulation, but in the detection of the 'special condition'. The correctness of the simulation is only relevant because it is used as input for the code to detect the 'special condition'. The proof that the halting problem cannot be solved with a computation implies that Olcott's detection of the 'special condition' cannot be correct.
It is probable that Olcott understands that it cannot be correct and therefore he hides the code for the recognition of this 'special condition'.
He probably knows that if he would publish this part of the decider, people would spot many errors in it immediately.
He has only shown some trivial examples as evidence that this detection of the 'special condition' is correct, such as Infinite_Loop and Infinite_Recursion, but, of course, a few trivial examples do not prove the correctness of this algorithm.
Therefore, he keeps pulling the attention away from the correctness of the detection of the 'special condition', to the correctness of the simulation.

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