XPost: comp.theory, sci.logic
On 8/1/25 10:31 AM, olcott wrote:
On 8/1/2025 7:38 AM, Alan Mackenzie wrote:
olcott <[email protected]> wrote:
[ .... ]
Alternatively halt deciders never were accountable
for the direct execution of their inputs because
no Turing machine can take a directly executing
Turing machine as an input.
It's not clear what you mean by a "directly executing turing machine".
Turing machines are abstract constructs which only secondarily can be
physically instantiated. What does it mean for a TM to be "directly
executing", and how does that differ from "indirectly executing"?
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.embedded_H is the Lina Halt Decider H.
Definition of the Linz Turing Machine Ĥ
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches
its simulated final halt state of ⟨Ĥ.qn⟩, and
No, if Ĥ applied to ⟨Ĥ⟩ reaches a final state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
if ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly
reach its simulated final halt state of ⟨Ĥ.qn⟩.
No, if Ĥ applied to ⟨Ĥ⟩ will never reach a final state after an
unbounded number of steps
It might be best to read the whole four page Peter Linz
proof to get the full background.
Maybe you should, and stop lying about what it says.
My augmentation to the Turing machine proof is to
assumed that Ĥ.embedded_H is based on a UTM. Thus a
simulating halt decider.
Ĥ applied to ⟨Ĥ⟩ is direct execution.
⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H is not direct execution.
But the criteria is if Ĥ applied to ⟨Ĥ⟩ reaches a final state, i.e the direct exection,
It was NEVER about the simulation done by Ĥ.embedded_H so you can't
change it to that.
All you are doing is showing that you don't know what you are talking
about and don't mind lying about it.
Halt deciders are only accountable for the behavior
that their input finite string Turing machine
description specifies.
If the initial state of the TM's tape can be construed as a string, then
yes.
It is a sequence of tape cells containing values, thus
essentially a string. For halt deciders this finite string
must be a machine description.
Right, the the correct answer for the halt decider is based on the
direct execution of the machine it is a description of.
This is only different than the direct execution
of the underlying machine when the input calls
its own decider (in recursive simulation).
Again, you haven't defined "direct execution".
I have defined it above.
It is unclear what you mean by "its own decider". What, for example, is
the decider of a program which adds two integers? I think you're getting >> confused between a purported decider "having" a program which breaks it
(which they all do), and an arbitrary program "having" a decider (which
is non-sensical).
When Ĥ applied to ⟨Ĥ⟩ then Ĥ.embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ we have one machine that contains a decider and this same
machine is applied to its own machine description.
The interesting part comes next.
But, since we don't care about what the PARTIAL (and thus not correct) simulation shows, the rest is just lies.
All you are doing is admitting that you haven't properly defined or used
your machine description language, or the "behavior" of that string
would match the behavior of the directly executed machine.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)