Re: Turing Machine computable functions apply finite string transformations to inputs VERIFIED FACT

On 4/30/2025 2:30 PM, Mike Terry wrote:

On 30/04/2025 16:46, Richard Heathfield wrote:

On 30/04/2025 16:15, olcott wrote:

On 4/29/2025 5:03 PM, Richard Heathfield wrote:

On 29/04/2025 22:38, olcott wrote:
>
<snip>
>

>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}
>
HHH is correct DD as non-halting BECAUSE THAT IS
WHAT THE INPUT TO HHH(DD) SPECIFIES.

>
You're going round the same loop again.
>
Either your HHH() is a universal termination analyser or it isn't.

>
The domain of HHH is DD.

>
Then it is attacking not the Halting Problem but the Olcott Problem, which is of interest to nobody but you.

 It would be (if correct) attacking the common proof for HP theorem as it occurs for instance in the Linz book which PO links to from time to time.
 The proof proceeds by assuming H is a halt decider.  Then it constructs from H a new TM H^ by modify H in a prescribed manner.  The proof shows that H fails to correctly decide input (<H^>,<H^>):  if H(<H^>,<H^>) = halts, then H^(<H^>) never halts, while if H(<H^>,<H^>) = neverhalts then H^(<H^>) halts.  So H is in fact NOT a halt decider.  (Alternatively the proof could be taken as proving that every halt decider H decides at least one input [viz H^] incorrectly.
 PO claimed to have constructed a TM H, and its corresponding TM H^, such that H /correctly/ decides input (<H^>,<H^>).  Since the Linz (and similar) proof shows H /incorrectly/ decides that input, there would clearly be some problem with proof, assuming PO's claims to be correct.
 So PO's H does not need to correctly decide every input - PO does not claim to have a valid halt decider.  His claim is that the Linz and similar proofs are invalid, so his H just has to decide that one input (<H^>,<H^>) correctly.
 Well by now you must be on the edge of your seat!  How did it all turn out?  Did PO in fact have the TMs he claimed?  What actually happens when you run those TMs???? !   (LOL)
 You'll be highly disappointed (but not too surprised) to learn:
1)  PO didn't have any TMs, and didn't know what a TM was.
2)  PO was trying to make C program analogs of the TMs, but he didn't have those either
     (at the time he claimed to have them)
3)  Eventually PO did produce some code in the form of his H and H^, but when you ran them:
     -   H^(<H^>) halts
     -   H(<H^>,<H^>) decided neverhalts
     Exactly in line with the Linz proof.  (PO's names differ from what I've used.)
 All the current threads are variations of PO trying to claim that H is "correct" in some wacky PO-sense, when it decides neverhalts for input (<H^>,<H^>), despite the acknowledged fact that H^(<H^>) actually halts.
  Mike.
 

What he's basically claiming is that the halting criteria *should* be that H(X,Y) computes what would happen if the code of H was replaced with an unconditional simulator and H(X,Y) is subsequently run.
In fact he's explicitly admitted this:
On 2/22/2025 1:02 PM, olcott wrote:
 > On 2/22/2025 11:10 AM, dbush wrote:
 >> On 2/22/2025 11:43 AM, olcott wrote:
 >>> The first point is DD correctly simulated by HHH cannot
 >>> possibly terminate normally by reaching its own "return"
 >>> instruction.
 >>
 >> In other words, if the code of HHH is replaced with an unconditional simulator then it can be shown that DD is non-halting and therefore HHH(DD)==0 is correct.
 >>
 >
 > Wow finally someone that totally gets it.
This is essentially the same as the halting criteria in cases where X does not call H at some point, but not in cases where it does.  He doesn't understand that he's changing the input in this case.
Lately we've been telling him that "direct execution" is what is decided on, as 1) it's the actual requirement, and 2) that it essentially enforces that the input can't be changed in a way that PO can understand.
A lot of this boils down to the fact that proof by contradiction is over his head, despite the fact that it's something high school students learn and understand.