Re: Defining a correct simulating halt decider

On 9/3/24 2:40 PM, olcott wrote:

On 9/3/2024 9:42 AM, joes wrote:

Am Mon, 02 Sep 2024 16:06:24 -0500 schrieb 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.

Which DDD does not.

 DDD emulated by HHH cannot possibly reach
its final halt state no matter what HHH does.

Of course it does, because the HHH that it calls aborts and returns to it.
You are confusing the PROGRAM DDD, which happened to be emulated by HHH, with the emulation of DDD by HHH, which is a different thing.
This apparently INTENTIONAL confusion (since you don't correct yourself after the error is exposed) just shows that you are being INTENTIONALLY deceptive and a pathological liar.

 

A halt decider never ever computes the mapping for the computation
that itself is contained within.

Then it is not total.

 Yes it is you are wrong.

No. Just proves you are a stupid liar.

 

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.

Which makes this pathological input a counterexample.

 Which makes the pathological input a counter-example
to the false assumption that the direct execution of
a machine always has the same behavior as the machine
simulated by its pathological simulator.

Nope, since you can't point out which instruction was CORRECTLY emulated that differed in behavior.
All you have shown is that HHH, if it DOES correctly emulate the input (meaning the call HHH instructions go into HHH) then all it sees is exactly the same execution trace as the directly executed DDD (unless HHH isn't a pure function) until it gives up an aborts.
That does NOT show that the "correct simulation by HHH" is different then the direct execution, it shows that HHH makes an incorrect deduction about the behavior when it decides to abort and the "guess" based on lies what the behavior will be.

 

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.

 

It is not simulating the abort because of a static variable. Why?
>

 void DDD()
{
   HHH(DDD);
   OutputString("This code is unreachable by DDD emulated by HHH");
}

But DDD when run will get there, as will DDD correctly and fully emulated by HHH1.

 

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.

 

Your HHH incorrectly changes behaviour.
>

 No you are wrong !!!
 

No, you are LYING because it seems you don't even KNOW what a CORRECT emulation actualy is, or what it means by the behavior of DDD.