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

On 4/30/25 3:35 PM, olcott wrote:

On 4/30/2025 1: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.
>

 This is not a Turing computable function to calculate sum
because it ignores its inputs thus does not transform them
according to the transformation rules of arithmetic.
int sum(int x, int y) { return 5; }

It is clear that you don't understand what the words you use mean.
"Computable Functions" are just mapping that happen to have a Turing Machine that computes them.
THey are NOT the code that does that computation.

 A halt decider is not allowed to compute halting on
the basis of direct execution. It is only allowed to
transform inputs into outputs.

But the correct answer *IS* determined by that.

 There are ONLY finite string transformations according
to the x86 language from the input to HHH(DD) to non
halting behavior.
 

Which is *EXACTLY* what the direct execution does.
And is *NOT* what HHH does, as it INCORRECTLY stops its operation.
It is clear you don't know what you are talking about

 

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.

 That is stupidly incorrect.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation

Until the emulation started in (c) aborts its emulation, and then transitions to Ĥ.qn, at which point Ĥ. halts.
It *WILL* do that since that is what H does (since you say it does that because of this reasoning) and embedded_H is a copy of the exact algorithm of H and thus does exactly the same steps as H does.
Since H gives up before it sees that embedded_H will do this, it gets the wrong answer because its programmer used unsound logic to write his program.

 

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.
>