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

On 7/12/25 7:53 AM, Mr Flibble wrote:

On Sat, 12 Jul 2025 10:17:55 +0200, Fred. Zwarts wrote:
>

Op 11.jul.2025 om 23:05 schreef olcott:

On 7/11/2025 3:52 AM, Fred. Zwarts wrote:

Op 10.jul.2025 om 16:35 schreef olcott:

On 7/10/2025 5:54 AM, Fred. Zwarts wrote:

Op 09.jul.2025 om 15:02 schreef olcott:>

All Turing machine deciders only compute the mapping from their
actual inputs. This entails that they never compute any mapping
from non-inputs.

>
At least one thing you understand.
>
>

*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
>
*The Linz proof does not understand this*
>
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
    *if Ĥ applied to ⟨Ĥ⟩ halts, and*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
    *if Ĥ applied to ⟨Ĥ⟩ does not halt*
>
>
>

The evidence is that the input includes the code to abort and
halt,

>
abort and stop running *IS NOT THE SAME THING AS*
abort and halt

>
Another claim without evidence.
>
>

*It is common knowledge in the theory of computation*
>
>

Another claim without evidence.
>
>

*Your lack of knowledge of computer science is not a rebuttal*
>
Look at the definition of a Turing Machine (e.g., the one here). The
machine has states. Each state can be final or non-final. If the
machine's state is non-final, in the next step the machine "does"
something, namely, it can write something on the tape, move its head,
and/or change its state to a different state. This is how the machine
makes a progress.

>
So, aborting the simulation when the machine has not yet reached its
final state, is a violation of the Turing Machine.

>
Nonsense, if that was true static code analysers wouldn't be a thing.
>
/Flibble

 Sure it could be. Note the difference between RUNNING a program and ANALYSIZING a program.
 The ONLY thing that actually determines the behavior of a Turing Machine is its behavior when actually run,