Re: Defining a correct simulating halt decider

On 9/3/24 9:25 AM, olcott wrote:

On 9/3/2024 2:07 AM, Fred. Zwarts wrote:

Op 02.sep.2024 om 23:06 schreef olcott:

On 9/2/2024 12:52 PM, Fred. Zwarts wrote:

Op 02.sep.2024 om 18:38 schreef olcott:

A halt decider is a Turing machine that computes
the mapping from its finite string input to the
behavior that this finite string specifies.
>
If the finite string machine string machine
description specifies that it cannot possibly
reach its own final halt state then this machine
description specifies non-halting behavior.
>
A halt decider never ever computes the mapping
for the computation that itself is contained within.
>
Unless there is a pathological relationship between
the halt decider H and its input D the direct execution
of this input D will always have identical behavior to
D correctly simulated by simulating halt decider H.
>
*Simulating Termination Analyzer H Not Fooled by Pathological Input D*
https://www.researchgate.net/ publication/369971402_Simulating_Termination_Analyzer_H_is_Not_Fooled_by_Pathological_Input_D
>
A correct emulation of DDD by HHH only requires that HHH
emulate the instructions of DDD** including when DDD calls
HHH in recursive emulation such that HHH emulates itself
emulating DDD.

>
Indeed, it should simulate *itself* and not a hypothetical other HHH with different behaviour.

>
It is emulating the exact same freaking machine code
that the x86utm operating system is emulating.

>
Even the best simulator will go wrong if it is given the wrong input.

 That is a stupid thing to say, you can see it was
given the correct input.

x86utm did the correct emulation.
The problem is that HHH doesn't correctly use that emulation, and presumes that the HHH that DDD calls isn't part of DDD, and that DDD actually calls some different HHH that doesn't abort.
Sorry, that is what you logic says, and just proves that you are a liar.

 

But the world class simulator, when given the DDD with the aborting HHH as input, that there is a halting program.
It is olcott's modified simulator that fails to reach the end of a halting program.
>

>

If HHH includes code to see a 'special condition' and aborts and halts, then it should also simulate the HHH that includes this same code and

>
>
DDD has itself and the emulated HHH stuck in recursive emulation.

>
Only for a few recursion and then HHH aborts, returns to DDD and DDD halts.
We see this in the direct execution, in the simulation by the world class simulator and even in the simulation by HHH1.
>

>
IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?
IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?
IS THE CONCEPT OF UNREACHABLE CODE OVER YOUR HEAD?

>
>
I know what unreachable code is. But it seems that olcott does not understand that unreachable code has nothing to do with the halting program.
>
    goto END;
>
    printf ("This is unreachable code!"\n);
>
END: return
>
>

>
void Infinite_Recursion()
{
   Infinite_Recursion();
   printf("Fred is too dumb to know this code is never reached!\n");
}
>
>

>
Again olcott seems to be unable to process the English language.
I never said that there was an infinite recursion. The infinite recursion is only in olcotts dream of the HHH that does not abort.
>
Olcott misses the fact that, when the aborting HHH simulates itself, there are only a few recursions and then it halts, a bit like:
>
void Finite_Recursion (int N) {
   if (N > 0) Finite_Recursion (N - 1);
   printf ("Olcott thinks this message is never printed!\n");
}
>
It looks as if it is impossible for him to understand that more than one recursion is not equivalent to an infinite recursion.