Re: Defining a correct simulating halt decider

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

On 9/8/2024 7:46 AM, joes wrote:

Am Sat, 07 Sep 2024 08:56:02 -0500 schrieb olcott:

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

On 2024-09-06 11:42:48 +0000, olcott said:

On 9/6/2024 6:19 AM, Mikko wrote:

On 2024-09-05 13:24:20 +0000, olcott said:

On 9/5/2024 2:34 AM, Mikko wrote:

On 2024-09-03 13:00:50 +0000, olcott said:

On 9/3/2024 5:25 AM, Mikko wrote:

On 2024-09-02 16:38:03 +0000, olcott said:
>

A halt decider is a Turing machine that computes the mapping
from its finite string input to the behavior that this finite
string specifies.

A halt decider needn't compute the full behaviour, only whether
that behaviour is finite or infinite.

Like Sipser said.
>

New slave_stack at:1038c4 Begin Local Halt Decider Simulation
Local Halt Decider: Infinite Recursion Detected Simulation Stopped
Hence  HHH(DDD)==0 is correct

>
Nice to see that you don't disagree with what said.
Unvortunately I can't agree with what you say.
HHH terminates, so DDD obviously terminates, too.

>
DDD emulated by HHH never reaches it final halt state.

If that iis true it means that HHH called by DDD does not return and
therefore is not a ceicder.

The directly executed HHH is a decider.

>
If the called HHH behaves differently from the direcly executed HHH
then the DDD is not relevant to classic proofs of the impossibility of
a halting decider.
If you can't show encoding rules that permit the encoidng of the
behaviour of the directly executed DDD to HHH then HHH is not a halting
decider.

I SHOW THE ACTUAL EXECUTION TRACE AND EVERYONE DISAGREES WITH IT.

Your implementation is buggy.
>

 X86utm is based on a world class x86 emulator that
has had decades of development effort. It has been
trivial to verify to the execution traces that it
produces are correct for three years.
 

Right, and the traces prove that DDD will return, and thus HHH is wrong.

It really seems quite ridiculous to me that everyone
could continue to disagree with such easily verified
facts without malevolent motives.

But *YOU* are the one that ignores the obvious facts, and tries to put forward LIES and EDITED TRACES as your proof.
Sorry, you just sunk your arguement.

 void DDD()
{
   HHH(DDD);
   return;
}
 Is the dumbed down version of the haling problem pathological input:
 int DD(int (*x)())
{
   int Halt_Status = HH(x, x);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 I dumbed it down as much as possible and people still don't get
it. They seem to believe that they are free to disagree with the
x86 language.

No, you have dumbed YOURSELF down to the point that you can't understand what the actual problem is, because yopu just can't understand the basic logic. You confuse the partial emulation that the decider does with the actual behavior of the input (which is what the problem is about) because you fundamentally don't understand the difference between knowledge and truth, and can't comprehend that there can be unknowable truth.

 It is like they believe that Trump actually won twice as many
votes as there are voters and cannot be convinced otherwise.
 

No, that is EXACTLY the sort of thought pattern that *YOU* are using. The fact that HHH can't find it out means it can't happen.
Sorry, you are just proving your stupidity.