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

On 7/16/25 11:34 AM, olcott wrote:

On 7/16/2025 3:05 AM, Fred. Zwarts wrote:

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

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

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(RRR);
   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.

>
_DDD()
[00002192] 55             push ebp
[00002193] 8bec           mov ebp,esp
[00002195] 6892210000     push 00002192  // push DDD
[0000219a] e833f4ffff     call 000015d2  // call HHH
[0000219f] 83c404         add esp,+04
[000021a2] 5d             pop ebp
[000021a3] c3             ret
Size in bytes:(0018) [000021a3]
>
So when the actual behavior of the actual x86 code
disagrees with you you disagree with the x86 language.
>

>
And since it does not disagree with me,

Show how DDD emulated by HHH
(according to the semantics of the x86 language)
reaches its "ret" instruction final halt state.
 Don't fucking change the subject to something else.
 

That isn't our problem.
YHOUR problem is YOU need to prove that it DOES a correct simulation, even though the code for HHH isn't in the input.
The definition of non-halting references the behavior of the DIRECT EXECUTION of the PROGRAM that the input represents.
Since you input doesn't include HHH, it isn't a program, and thus doesn't have a halting property, and you arguement blows up in a category error.