Re: Refutation of Turing’s 1936 Halting Problem Proof Based on Self-Referential Conflation as a Category (Type) Error

On 4/25/25 5:46 PM, olcott wrote:

On 4/25/2025 11:54 AM, Richard Damon wrote:

On 4/25/25 12:31 PM, olcott wrote:

On 4/25/2025 3:46 AM, Mikko wrote:

On 2025-04-24 15:11:13 +0000, olcott said:
>

On 4/23/2025 3:52 AM, Mikko wrote:

On 2025-04-21 23:52:15 +0000, olcott said:
>

Computer Science Professor Eric Hehner PhD
and I all seem to agree that the same view
that Flibble has is the correct view.

>
Others can see that their justification is defective and contradicted
by a good proof.
>
Some people claim that the unsolvability of the halting problem is
unproven but nobody has solved the problem.

>
For the last 22 years I have only been refuting the
conventional Halting Problem proof.

>
Trying to refute. You have not shown any defect in that proof of the
theorem. There are other proofs that you don't even try to refute.
>

>
Not at all. You have simply not been paying enough attention.
>
Once we understand that Turing computable functions are only
allowed to derived their outputs by applying finite string
operations to their inputs then my claim about the behavior
of DD that HHH must report on is completely proven.
>

>
Youy have your words wrong. They are only ABLE to use finite algorithms of finite string operations. The problem they need to solve do not need to be based on that, but on just general mappings of finite strings to finite strings that might not be described by a finite algorithm.
>
The mapping is computable, *IF* we can find a finite algorith of transformation steps to make that mapping.
>

 There are no finite string operations that can
be applied to the input to HHH(DD) that derive
the behavior of of the directly executed DD thus
DD is forbidden from reporting on this behavior.

Of course there is a finite string transformation that can be applied to the input of HHH(DD), ie the code of DD, as that transformation is the transformation defined by the x86 language, or the FULL AND COMPLETE emulation of the input DD.
It just is a fact that this isn't the transformation that HHH does, but is what HHH1 does.

 It is forbidden for the same reason that
int sum(int x, int y) { return x + y; }
sum(3,2) IS NOT ALLOWED TO REPORT ON THE SUM OF 5 + 7.
 

But the input to HHH is the object code of DD, not what that does. It is HHH's job to figure out what it does.
Just like sum(3,20 is given the number 3 and 2, and it needs to figure out what the sum of those numbers are.
Remember, you have stipulated that the input DD includes the code defined by Halt7.c, so HHH has been given all the code of itself. This is enough information to determine the behavior, as HHH1 shows, it is just that HHH doesn't do that, and DD capitalizes on that error in HHH to make it wrong.
Now, of course if you make some different decider, say UTM that doesn't do that abort, then DDUTM which calls that UTM instead of HHH, will cause UTM(DDUTM) to not answer, and thus fail to be a decider, showing that DDUTM acheived its goal.