Re: What it would take...

Op 10.mei.2025 om 17:07 schreef olcott:

On 5/9/2025 9:18 PM, Richard Damon wrote:

On 5/9/25 9:11 PM, Richard Heathfield wrote:

The HHH code doesn't exactly invite confidence in its author, and his theory is all over the place, but a thought experiment suggests itself.
>
If we were not all wasting our time bickering with a career bickerer... if we were to really /really/ try, could we patch up his case and send him on to his Turing Award? And if so, how?
>
ISTR that there is suspected to be a theoretical window for him, so I suppose what I'm asking is what sort of boathook we would need to poke that window a little wider.
>
Can he even get there from here? Evidence would suggest that simulation is a dead end unless he can find a way to get the simulated program to include its own simulation in its behaviour, which he has not yet managed to do - but /is/ there a way?
>
Or could he abandon simulation completely and instead write a TM parser that builds an AST and walks it looking for evidence of terminating or looping? If he could, would that turn the trick?
>
Or do we have a latter day Cantor waiting in the wings to close the window once and for all?
>
Is there, in short, any way of putting out this un-halting flame war and turning this group to better use?
>

>
If he was willing to include the code for HHH in the input representing DDD, then HHH would be able to atempt to correctly emulate this input.
>

 DDD and HHH have always been in the same memory space.
DDD is the program under test and HHH is the test program.

And because DDD calls HHH, HHH (with the conditional abort) is part of the input.

 

There have been methods put forward, that given an acceptace of the detectability of DDD calling HHH, which can only be done it seems if we make the system non-turing complete by saying that the input program and the decider are put into the same memory space, and we are not allowed to "copy" an algorithm to make a new copy, but only call the origianal version so HHH can detect the recursion by reference to that address that some versions of programs that do this "recursive simulation" can be correctly decider (but not all, like the pathological version).
>

 HHH is essentially a UTM thus EVERYTHING is in the memory space
of its UTM tape.

Except that HHH has a conditional abort, which makes that it is blind for the most important part of the input: the conditional abort. This bugs makes that HHH is unable to see the specified behaviour.

 

In this method, the Decider detecting the recursion, tries emulating the code in two parrallel branches based on both possible answers, and if one branch matches the behavior of the answer, it can return that answ3er.
>

 We can emulate a branch as if a conditional expression
was true and as if it was false. HHH determines the
behavior of DDD on the basis of what would happen if
HHH never aborted.

Which is not the input, because the input specifies a HHH that does abort. This change of input makes that HHH computes an incorrect mapping.

 <MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     *would never stop running unless aborted* then
 

Which is a vacuous statement, because it does not correctly simulate its input, but it simulates another input. The input specified a finite recursion, so the simulator is wrong when it decides that its simulated D would never stop.

Thus, inputs like DDD() that always halt on the return of HHH(DDD) will be correctly determined to be halting, and a varient that just goes into an infinite loop can be such detected by well know procedures as non- halting.
>

 When HHH continues to emulate DDD until HHH sees the
repeating pattern that would prevent DDD from ever
terminating

No, because it is only a finite repeating pattern, which would terminate, because the simulated HHH aborts.

      H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>

A vacuous statement, because the required conditions are not met.

 

The pathological DD() is detected as pathological, and we can perhaps extend the definition to allow it to respiond with an "I give up, I don't know the answer" response, but such an extention explicitly does NOT meet the requirements, but is better than not answering or giving a wrong answer.
>
The problem is this result doesn't meet Peter's Goal, as it isn't really the Halting Problem that he has his major problem with, but the fact that Turings Proof became the basis for a number of broader proofs of incompleteness and undeciability that fills formal logic.
>
This is what he can't handle, and this is because he just doesn't really understand how all of the works because his mental models of logic is just way to small and simple.

 Dodge and weave is all you know.
 int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
 It is a verified fact that DD correctly emulated
by any simulating termination analyzer HHH specifies
a non-terminating sequence of configurations.

Only if HHH does not abort. If HHH aborts, it returns to DD and DD halts. A correct simulation should see that.