Re: Incorrect requirements --- Computing the mapping from the input to HHH(DD)

On 5/10/25 9:56 PM, olcott wrote:

On 5/10/2025 8:44 PM, wij wrote:

On Sat, 2025-05-10 at 20:26 -0500, olcott wrote:

On 5/10/2025 8:17 PM, wij wrote:

On Sat, 2025-05-10 at 17:03 -0500, olcott wrote:

On 5/10/2025 4:44 PM, wij wrote:

On Sat, 2025-05-10 at 14:29 -0500, olcott wrote:

On 5/10/2025 2:02 PM, wij wrote:

>

>
You don't know the counter example in the HP proof, your D is not the case what HP says.
>

>
Sure I do this is it! (as correctly encoded in C)
>
typedef void (*ptr)();
int HHH(ptr P);
>
int DD()
{
    int Halt_Status = HHH(DD);
    if (Halt_Status)
      HERE: goto HERE;
    return Halt_Status;
}
>
int main()
{
    HHH(DD);
}
>
>

>
Try to convert it to TM language to know you know nothing.
>

 I spent 22 years on this. I started with the Linz text

You mean you have wasted 22 years on this.

 When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞

Missing the qualification, if Ĥ ⟨Ĥ⟩ will halt

   or
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

Missing the qualification, if Ĥ ⟨Ĥ⟩ will not halt
And those qualifications are based on H being correct.

 (a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...
 Thus ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H
cannot possibly reach its simulated final halt state
⟨Ĥ.qn⟩

but step (c) will stop after some finite time when embedded_H does the exact same process as H did when it reaches it conclusion (which it follows exactly as it is exactly the same algorithm on the same data) at which point it will stop and go to Qn and Ĥ ⟨Ĥ⟩ will halt, thus showing that H returned the wrong answer for H ⟨Ĥ⟩ ⟨Ĥ⟩, as in this case, to be correct H should have ended up in Qy instead of Qn.

 

To refute the HP, you need to understand what it exactly means in TM.

 I have known this for 22 years.

No, and you still don't as far as everything you have said.
You confuse where the requirements are, and even ignore and drop them becuase of your ignorance.
You don't seem to understand that programs are deteministic entities that will always do the same thing on the same input.

 

Assembly (or C) also work, but you need to understand more details and
be able to map every assembly instruction or C expressions to TM language.
The form of the DD above (in some books maybe) is for layman to understand,
which is not exactly the case that the HP provides. Don't be silly.
>