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

Op 14.jul.2025 om 15:25 schreef olcott:

On 7/14/2025 4:19 AM, Fred. Zwarts wrote:

Op 13.jul.2025 om 17:38 schreef olcott:

On 7/13/2025 1:09 AM, Fred. Zwarts wrote:

Op 12.jul.2025 om 17:21 schreef olcott:

On 7/12/2025 3:17 AM, 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.
>

>
void DDD()
{
   HHH(DDD);
   return;
}
>
So you don't understand that DDD simulated by
pure simulator HHH keeps repeating its first
line forever?

>
Irrelevant, because that is not what HHH does.

>
void DDD()
{
   HHH(DDD);
   return;
}
>
I stipulated this HHH <is> a pure simulator temporarily
overriding and superseding everything else that I ever
said about HHH.

>
You can stipulate that, but is irrelevant for the HHH you published in Halt7.c. *That* HHH is not a pure simulator. The fact that a pure simulator fails is no proof for the correctness of the non-pure simulator.
Dreaming of other simulators with other behaviour does not change the factual behaviour of the HHH we are discussing.
>

 void RRR()
{
   SSS(DDD);
   return;
}
 When RRR is simulated by pure simulator SSS
RRR simulated by SSS never reaches its own
"return" statement.

You have been corrected on this many times, but you seem unable to understand it.
We are discussing a non-pure simulator, so the behaviour of a pure simulator is irrelevant.

 When we adapt SSS so that it only simulates
N instructions of RRR then no RRR ever reaches
its own "return" statement.

Now there is a final halt state, but SSS is unable to reach it. This illustrates that simulation is not the right tool for this input to analyse the behaviour, because it cannot see the full specification. Other tools are needed, but each tool will fail for some inputs.