Re: Defining a correct halt decider

On 9/8/24 10:01 AM, olcott wrote:

On 9/8/2024 4:27 AM, Mikko wrote:

On 2024-09-07 13:54:04 +0000, olcott said:
>

On 9/7/2024 3:03 AM, Mikko wrote:

On 2024-09-06 11:41:05 +0000, olcott said:
>

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.

>
I don't know about you but most of the participants of this discussion
seem to understand recursive simulation and how it differs from
recursion.

>
Both Fred and Joes think that you can just wait for it
to end on its own. Neither one of them ever answered
when I asked them: Do you know what infinite recursion is?

>
Recursion is a fairly simple concept but do you understand what
"infinite" means?
>

 Unless the outer directly executed HHH aborts its
emulation of DDD it is infinite recursive emulation.
 Whether or not the outer directly executed HHH aborts
its emulation DDD never reaches its "return" instruction
final halt state thus cannot possibly halt.
 

But we aren't being asked about the emulation of DDD by HHH, we are being asked about the behavior of DDD that HHH was emulationg.
That behavior doesn't stop when the emulation stops, as the x86 language doesn't define behavior that way. The behavior continues, and since HHH has been shown to abort its emulation and return, the HHH that DDD calls (as a top level program, or correctly emulated by HHH if it *IS* a pure function) will also return to DDD, and thus DDD is a HALTING program.
Sorry, you are just proving your stupidity for beleiving your own lies and working on your own strawman problem.