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

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 Ĥ. This Ĥ includes the code that make it halt, so the specification is a halting program. Nowhere there is the requirement that it must report on the direct execution.
Direct execution is only one way to prove what is specified in the input, but often there are other methods to prove it. Ĥ does not need to know it, it show only report what is specified. If it fails to report that a halting program halts, it is just wrong.