Re: My reviewers think that halt deciders must report on the behavior of their caller

Op 09.jul.2025 om 15:16 schreef olcott:

On 7/9/2025 4:04 AM, Fred. Zwarts wrote:

Op 08.jul.2025 om 16:31 schreef olcott:

On 7/8/2025 2:55 AM, Fred. Zwarts wrote:

Op 08.jul.2025 om 04:52 schreef olcott:

On 7/7/2025 9:24 PM, Richard Damon wrote:

On 7/7/25 7:47 PM, olcott wrote:>>

That Turing machines cannot take directly executing Turing
Machines as inputs entails that these directly executed
machines are outside of the domain of every Turing machine
based halt decider.

>
But they can take the finite-stringt encoding of those machines.
>

>
Yes.
>

I guess you idea of Turing Machine is so limited that you think they can't do arithmatic, as you can't actually put a "Number" as the input, only the finite-string encoding of a number, which puts it outside the domain of them.
>

>
No one here has any understanding of the philosophy of
computation. They can only memorize the rules and have
no idea about the reasoning behind these rules.
>

>
That you cannot understand that is a truism is only your
own lack of understanding.

>
But it isn't a truism, it is just a stupid lie that ignores that almost everything done with programs is via an "encoding" for the input.
>

>
Gross ignorance about the reasoning behind the rules
of computation would tell you that.
>

>
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
*Here is the Linz proof corrected to account for that*
>
*adapted from bottom of page 319*
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
     its simulated final halt state of ⟨Ĥ.qn⟩
>
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
     ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
     reach its simulated final halt state of ⟨Ĥ.qn⟩
>
>

>
Which is just an admission of your lying strawman, as the question is NOT about the (partial) simulation done by your H / embedded_H, but about the direct execution of the input H^ (H^) as that is what the input to H is encoding.
>

>
Because no Turing machine can take a directly executed
Turing machine as an input, directly executed Turing
machines have always been outside of the domain of every
Turing machine based decider.
>
"the direct execution of the input H^ (H^)" has always been
out-of-scope for every Turing machine based halt decider.
That no one bothered to notice this ever before
*DOES NOT MAKE ME WRONG*

That is your misconception. No one ever asked to take the direct execution as input.

>
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
   if Ĥ applied to ⟨Ĥ⟩ halts
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
   if Ĥ applied to ⟨Ĥ⟩ does not halt
>
*The above original form of the proof*
does requires Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ to report on
the direct execution of Ĥ applied to ⟨Ĥ⟩ and thus
not ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H.
>

Your are fighting windmills. Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to report on the specification of its input Ĥ.

 Very close.
Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ is required to report
on the behavior that its input specifies.
 

This Ĥ includes the code that make it halt,

 More precisely This Ĥ includes one final halt state: Ĥ.qn
That is unreachable when ⟨Ĥ⟩ ⟨Ĥ⟩ is correctly simulated by
Ĥ.embedded_H.

But being unreachable by Ĥ is a failure/property of Ĥ, not of the input.
The conclusion must be that Ĥ fails to reach the end of the simulation.
Another evidence that it is not possible to create a generic decider that reports correctly on any input. In this case Ĥ fails on this input by not reaching the end.
This has been explained many times to you, but your refuse to learn from your errors.