From Newsgroup: comp.theory

On 9/6/25 1:55 PM, Mike Terry wrote:

On 06/09/2025 13:56, Richard Damon wrote:

On 9/5/25 11:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

On 9/5/25 1:06 PM, olcott wrote:

On 9/5/2025 11:01 AM, André G. Isaak wrote:

On 2025-09-05 08:16, olcott wrote:

On 9/4/2025 10:06 PM, André G. Isaak wrote:

On 2025-09-04 20:57, olcott wrote:

M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞  // accept state >>>>>>>>> M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state >>>>>>>>

That's your syntax. It's not "more conventional". It's just
muddled.

As I already established Sipser, Kozen and Hofcroft
all use M for Turing machine M.

It's not your use of M that I am objecting to. It is your use of M.H. >>>>>>

Linz does this same thing in an objectively
incorrect way by giving Ĥ two different start states.
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.

And what is incorrect about this?

Ĥq0  is just the name in M for the state of the beginning of the
algorithm of H, the state that was q0 in H.

That's not what Linz's notation means.  Part of the problem is
reflecting the Linz typesetting here in these posts.  In the expression >>>       q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞

both the * and Ĥ are joined to the ⊢ symbol.  * is a superscript,
indicating some unspecified number of ⊢ steps.  Ĥ is a subscript to >> the > ⊢ indicating the machine performing the stepping, i.e. it says the >>> unspecified number of steps are according to Ĥ's state transition
rules.  Hmm, also the WM is actually W subscripted by M.  (Both W and >>> M separately already having their own meanings in the proof.)

Representing the subscript relationship in these posts is awkward.
Traditionally posters have used _ (underscore) for this, in which
case Linz's notion would be properly quoted here as

   q_0 W_M  ⊢*_Ĥ  q_0 W_M W_M  ⊢*_Ĥ  ∞

(Linz's notation omits the spaces, because the typesetting is (not
great, but) better than in these usenet posts.)  Or we might get away
with

   q0 WM  ⊢*Ĥ  q0 WM WM  ⊢*Ĥ  ∞

if we say we'll always put spaces between separate tokens, so it will
be clear e.g. that WM is W subscripted by M, not W followed by M.

Or just assuming the machine Ĥ is understood through context, so it
becomes just

   q0 WM  ⊢*  q0 WM WM  ⊢*  ∞

Anyway, Ĥq0 is not the compound symbol you're suggesting...  And it
does seem Linz has used state q0 twice with different meanings!  :(
Well, it is perfectly obvious how that should be fixed - an erratum
sure, but hardly a problem with the proof itself.

(Yeah, the notation is a bit of a mess for representing in a pure
character string format. Personally I think using qualified state
labels such as H.q0 is reasonable, and also using <M> to indicate the
string description of M seems clearer than WM or W_M.  But such
things need explaining...)

Mike.

That's not how I read his notation.

For each state in the process, we list the state name, possible
preceeded and followed by the tape contents with the state name being
tape head pointer.

Right.

Listing of states of H that have been copied into Ĥ are then preceeded
by a subscript Ĥ to mark that transfer.

No, the Ĥ is a subscript to the ⊢.  He explains that in an earlier chapter of the book.  (And never mentions anything about any business of marking the code transfer like that.)

Let's see...  so in my copy (5th Edition) it's in Section 9.1 "The
Standard Turing Machine", just after Example 9.4.  There are plenty of following examples of the machine subscript used that way.

Ok, I don't have the book, but going on the material presented.

It seems to be a bad notation, as you KNOW what machine you are tracing
from the states being named.

There is no need to list the machine on the ⊢ symbol, as a given chart
is all of just one machine.

I suppose he considered that within the context of his HP proof there
were 3 machines (H, H', H^) so it would be worth qualifying the
machine.  Personally I agree that in each statement in the proof, the machine context is obvious enough..  And for sure on this forum the
machine in question is generally perfectly clear.

but it does mean his H^ now has two states named q0

This means the claim of the duplicate q0 state is wrong, as one is the
state q0, as the starting state of M/Ĥ, and the other state thought to
be also q0 is actually Ĥq0, (with Ĥ a pre-subscript) indicating the q0
state of H that has been copied into Ĥ

..if your reading were correct..

and not doing something to change the name means the example is incorrect.

Using dots instead of subscripts, and brackets instead of W prefix can
be a help for readability.

With that, the starting state of Ĥ is q0, but the copied starting
start of H would be Ĥ.q0 or H.q0 depending on if you are marking that
it was copied into Ĥ or from H, but either way, is distinct from q0.

But either way, the key point is that ⊢* doesn't mean "arbitrary
sequence" as in the machine can change what happens at each of the
steps, but that it is a "unspecified sequence" in that it isn't
listed, but for the given machine, the path *IS* fully defined.

Sure, no disagreement on that.  Also PO has said the notation is a "specification" of Ĥ, which is a complete misunderstanding.  The specification follows from Ĥ's definition earlier in the proof, and the oft-quoted lines that PO quotes using the notation are statements
concerning the action of Ĥ taking an input of WM.

Mike.

Just more of POs not understanding the basic principles of what he is
reading.

Seems that it doesn't help that he chose a source that isn't as good as
it could be.

Does Linz never describe how to form a representation of a machine, or s
thus just a blind spot of Peter's that he can't allow the input to
actualy represent the machine it is from?

That is an abstraction that seems to be beyond his ability.

That is the FACT that Olcott seems to miss. >

That he modifies H by appending the q.a <--> q.b
infinite loop states and then modifies this H' by
prepending more states proves that his Ĥq0 is more
correctly stated as Ĥ.H

Why do you say that.

Perhaps he could have called it Ĥ.Hq0 to mark that this is the
equivalent state to H's q0.

Note, Ĥ.H does NOT mean go out to find some other machine H, as
Turing Machines can't do that. It means this state in the machine Ĥ
is the mapping of the first state of H, whose algorithm has been
copied into here.

Sipser uses
⟨M⟩ for Turing machine description of M.

Linz uses
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.

and
∞ the traditional infinite loop at the halt state.

(a) M copies its input ⟨M⟩
(b) M invokes M.H ⟨M⟩ ⟨M⟩
(c) M.H simulates ⟨M⟩ ⟨M⟩

And what exactly does it mean for M to “invoke” M.H? TMs don't >>>>>> “invoke” things.

André

It means that M.q0 ⟨M⟩ transitions to its own
internal state of M.H ⟨M⟩ ⟨M⟩ after first copying
its input, essentially invoking its own internal
copy of H.

Yes, its own internal copy of H, the exact H that it was designed to
refute, and thus the H that WILL abort its simulation and return to
qn, as that is what you say your H will "correctly" do, but that
behavior is NOT correct, as this means that M (M) will halt, and
thus H (M) (M) was supposed to go to qy, which your doesn't, so your
H can't be that H, which actualy can't exist.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 12:55 PM, Mike Terry wrote:

On 06/09/2025 13:56, Richard Damon wrote:

On 9/5/25 11:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

On 9/5/25 1:06 PM, olcott wrote:

On 9/5/2025 11:01 AM, André G. Isaak wrote:

On 2025-09-05 08:16, olcott wrote:

On 9/4/2025 10:06 PM, André G. Isaak wrote:

On 2025-09-04 20:57, olcott wrote:

M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞  // accept state >>>>>>>>> M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state >>>>>>>>

That's your syntax. It's not "more conventional". It's just
muddled.

As I already established Sipser, Kozen and Hofcroft
all use M for Turing machine M.

It's not your use of M that I am objecting to. It is your use of M.H. >>>>>>

Linz does this same thing in an objectively
incorrect way by giving Ĥ two different start states.
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.

And what is incorrect about this?

Ĥq0  is just the name in M for the state of the beginning of the
algorithm of H, the state that was q0 in H.

That's not what Linz's notation means.  Part of the problem is
reflecting the Linz typesetting here in these posts.  In the expression >>>       q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞

both the * and Ĥ are joined to the ⊢ symbol.  * is a superscript,
indicating some unspecified number of ⊢ steps.  Ĥ is a subscript to >> the > ⊢ indicating the machine performing the stepping, i.e. it says the >>> unspecified number of steps are according to Ĥ's state transition
rules.  Hmm, also the WM is actually W subscripted by M.  (Both W and >>> M separately already having their own meanings in the proof.)

Representing the subscript relationship in these posts is awkward.
Traditionally posters have used _ (underscore) for this, in which
case Linz's notion would be properly quoted here as

   q_0 W_M  ⊢*_Ĥ  q_0 W_M W_M  ⊢*_Ĥ  ∞

(Linz's notation omits the spaces, because the typesetting is (not
great, but) better than in these usenet posts.)  Or we might get away
with

   q0 WM  ⊢*Ĥ  q0 WM WM  ⊢*Ĥ  ∞

if we say we'll always put spaces between separate tokens, so it will
be clear e.g. that WM is W subscripted by M, not W followed by M.

Or just assuming the machine Ĥ is understood through context, so it
becomes just

   q0 WM  ⊢*  q0 WM WM  ⊢*  ∞

Anyway, Ĥq0 is not the compound symbol you're suggesting...  And it
does seem Linz has used state q0 twice with different meanings!  :(
Well, it is perfectly obvious how that should be fixed - an erratum
sure, but hardly a problem with the proof itself.

(Yeah, the notation is a bit of a mess for representing in a pure
character string format. Personally I think using qualified state
labels such as H.q0 is reasonable, and also using <M> to indicate the
string description of M seems clearer than WM or W_M.  But such
things need explaining...)

Mike.

That's not how I read his notation.

For each state in the process, we list the state name, possible
preceeded and followed by the tape contents with the state name being
tape head pointer.

Right.

Listing of states of H that have been copied into Ĥ are then preceeded
by a subscript Ĥ to mark that transfer.

No, the Ĥ is a subscript to the ⊢.  He explains that in an earlier chapter of the book.  (And never mentions anything about any business of marking the code transfer like that.)

Let's see...  so in my copy (5th Edition) it's in Section 9.1 "The
Standard Turing Machine", just after Example 9.4.  There are plenty of following examples of the machine subscript used that way.

There is no need to list the machine on the ⊢ symbol, as a given chart
is all of just one machine.

I suppose he considered that within the context of his HP proof there
were 3 machines (H, H', H^) so it would be worth qualifying the
machine.  Personally I agree that in each statement in the proof, the machine context is obvious enough..  And for sure on this forum the
machine in question is generally perfectly clear.

This means the claim of the duplicate q0 state is wrong, as one is the
state q0, as the starting state of M/Ĥ, and the other state thought to
be also q0 is actually Ĥq0, (with Ĥ a pre-subscript) indicating the q0
state of H that has been copied into Ĥ

..if your reading were correct..

Using dots instead of subscripts, and brackets instead of W prefix can
be a help for readability.

With that, the starting state of Ĥ is q0, but the copied starting
start of H would be Ĥ.q0 or H.q0 depending on if you are marking that
it was copied into Ĥ or from H, but either way, is distinct from q0.

But either way, the key point is that ⊢* doesn't mean "arbitrary
sequence" as in the machine can change what happens at each of the
steps, but that it is a "unspecified sequence" in that it isn't
listed, but for the given machine, the path *IS* fully defined.

Sure, no disagreement on that.  Also PO has said the notation is a "specification" of Ĥ, which is a complete misunderstanding.  The specification follows from Ĥ's definition earlier in the proof, and the oft-quoted lines that PO quotes using the notation are statements
concerning the action of Ĥ taking an input of WM.

Mike.

Ĥ begins at its own start state that I call Ĥ.q0

Then Ĥ copies its input that Linz calls W_M and I call ⟨Ĥ⟩.

Then after ⊢* that Linz defines as "an arbitrary number of moves"
on page 237 Ĥ transitions to Ĥq0W_MW_M that I call Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩.

I call this Ĥ.H because Linz specifies that this is the first
state of his original H machine (template).
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional infinite
loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

(Yes, the latter is an example of never
terminating.)  Also the way you write

   Ĥq0 WM WM ⊢* Ĥ∞

above does not make sense - Ĥ∞ makes no sense being qualified by a machine name.  And in Linz it /isn't/.

*COUNTER FACTUAL* It short-hand for the state after the
qy state of the H' machine (template) on the top of page 319.
This same machine is adapted to become the Ĥ machine (template).

The Ĥ qualification is an
optional subscript for the /preceding/ ⊢ symbol.  That makes sense, even if people can argue it's unnecessary because the machine used is clear
from the context.

Subscripts cannot be cleanly represented in ASCII text.

Anyhow, all these points have been clarified many times in the past, but
in a few days time you will just post the same line with exactly the
same misunderstandings.  I suppose of all your problems this one is very minor...  At least these days you seem to recognise the need to qualify these lines with the circumstances to which they apply ("if M applied to
WM halts" etc.)

Mike.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/25 1:51 PM, olcott wrote:

On 9/5/2025 7:51 PM, Kaz Kylheku wrote:

On 2025-09-05, olcott <polcott333@gmail.com> wrote:

On 9/5/2025 6:09 PM, wij wrote:

No C function can possibly even see its own caller

False. C function can 'see' its own caller and even analyze its caller >>>> (the result may be wrong, though)

Its caller is a directly executing process
that no C function can possibly see.

Of course a function cannot look for its caller. There is no such thing;
pure functions do not have a caller.

In other words it is impossible to write a pure
function in C that is called by main()?

This is just one of the examples of needing to be very clear in the
meaning in context of the words.

A pure function is defined out of context, as its context doesn't
matter, and thus the function itself doesn't HAVE a caller.

The pure function can then be called from a context, and in that context
an instance of that function gets called.

There is a subtle distinction between the defintion of the function, and
the act of applying it in a given context.

Part of the confusion is that in computation theory, "Functions" are not things that are called, but a just pure mappings of input to outputs.

As such, they are not "called", but if they can be computed with a
finite algorithm, then a computation can implement it as part of its algorithm.

The world of C programming doesn't have such ideas as part of it. In particular, C doesn't have the concept of a "pure function", just
functions, as subroutines of code that work on their parameters and the
global address space to (normally) produce a result that they return or
store into global address space.

To try to model the Computation Theory concepts in C, you run into the
problem that C (or most programming languages) don't have any concept to
map the concept of the "Function" to, at best they can define things
that are the implementation of a "Computable Function".

This becomes part of your problem in trying to understand the problem,
as you want C to have something that is the Computation Theory Function,
when it just doesn't have anything like that, except at the meta-level
of a program requriements specification, something you don't seem to understand.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/25 1:50 PM, olcott wrote:

On 9/5/2025 7:47 PM, Kaz Kylheku wrote:

On 2025-09-05, olcott <polcott333@gmail.com> wrote:

I don't understand how you can't understand
that no C function can correctly analyze the
behavior of its caller.

I do understand that; but with the caveat that it's only true if that
caller contradicts the function. I.e. the caller is a diagnal case in
the halting proof, or a similar situation.

No C function c an see any aspect of the executing
process of its caller because that is just not the
way that C functions work.

Sure they can, *IF* they can use implementation defined behaviors to
allow them to access the rest of the stack.

This creates "Undefined Behavior" per the standard, but not in the implementation.

I have code that I use in processor exception traps that prints out the calling addres of the exception, as well as the register set in
existance at the time.

The code is dependent on the processor that it is run on, so isn't
"portable" but has fully defined behavior by the implementation.


Note, by your claim, HHH(DD) must always do the same thing, and thus if
this version of HHH(DD) is going to return 0, it must do so under the
analysis that ALL calls to HHH(DD) will also do that, and not the
assumption that some call to HHH(DD) will never return.

Your logic is just based on LIES and CONTRADICTIONS.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/25 2:23 PM, Chris M. Thomasson wrote:

On 9/5/2025 1:23 PM, Kaz Kylheku wrote:

On 2025-09-05, olcott <polcott333@gmail.com> wrote:

On 9/5/2025 12:26 AM, Kaz Kylheku wrote:

This is because simulation can be made conditional.

void Infinite_Recursion()
{
    Infinite_Recursion();
    return;
}

The question is not will the above function
run forever, it will not.

In the abstract realm of Turing, yes it will.

I still get a vibe that he is an ultrafiniteist in a sense... Humm...

[...]

I am sure that PO can't understand the actual concept of infinity.

All his logical examples that he does logically are purely finite in scope.

When he attempt induction, he has so little understanding that he can't actually build a proof in it.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/25 2:35 PM, olcott wrote:

On 9/6/2025 12:55 PM, Mike Terry wrote:

On 06/09/2025 13:56, Richard Damon wrote:

On 9/5/25 11:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

On 9/5/25 1:06 PM, olcott wrote:

On 9/5/2025 11:01 AM, André G. Isaak wrote:

On 2025-09-05 08:16, olcott wrote:

On 9/4/2025 10:06 PM, André G. Isaak wrote:

On 2025-09-04 20:57, olcott wrote:

M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞  // accept state >>>>>>>>>> M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state >>>>>>>>>

That's your syntax. It's not "more conventional". It's just >>>>>>>>> muddled.

As I already established Sipser, Kozen and Hofcroft
all use M for Turing machine M.

It's not your use of M that I am objecting to. It is your use of >>>>>>> M.H.

Linz does this same thing in an objectively
incorrect way by giving Ĥ two different start states.
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.

And what is incorrect about this?

Ĥq0  is just the name in M for the state of the beginning of the
algorithm of H, the state that was q0 in H.

That's not what Linz's notation means.  Part of the problem is
reflecting the Linz typesetting here in these posts.  In the expression >>>>       q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞

both the * and Ĥ are joined to the ⊢ symbol.  * is a superscript,
indicating some unspecified number of ⊢ steps.  Ĥ is a subscript >>> to the > ⊢ indicating the machine performing the stepping, i.e. it

says the

unspecified number of steps are according to Ĥ's state transition
rules.  Hmm, also the WM is actually W subscripted by M.  (Both W
and M separately already having their own meanings in the proof.)

Representing the subscript relationship in these posts is awkward.
Traditionally posters have used _ (underscore) for this, in which
case Linz's notion would be properly quoted here as

   q_0 W_M  ⊢*_Ĥ  q_0 W_M W_M  ⊢*_Ĥ  ∞

(Linz's notation omits the spaces, because the typesetting is (not
great, but) better than in these usenet posts.)  Or we might get
away with

   q0 WM  ⊢*Ĥ  q0 WM WM  ⊢*Ĥ  ∞

if we say we'll always put spaces between separate tokens, so it
will be clear e.g. that WM is W subscripted by M, not W followed by M. >>>>
Or just assuming the machine Ĥ is understood through context, so it
becomes just

   q0 WM  ⊢*  q0 WM WM  ⊢*  ∞

Anyway, Ĥq0 is not the compound symbol you're suggesting...  And it >>>> does seem Linz has used state q0 twice with different meanings!  :
( Well, it is perfectly obvious how that should be fixed - an
erratum sure, but hardly a problem with the proof itself.

(Yeah, the notation is a bit of a mess for representing in a pure
character string format. Personally I think using qualified state
labels such as H.q0 is reasonable, and also using <M> to indicate
the string description of M seems clearer than WM or W_M.  But such
things need explaining...)

Mike.

That's not how I read his notation.

For each state in the process, we list the state name, possible
preceeded and followed by the tape contents with the state name being
tape head pointer.

Right.

Listing of states of H that have been copied into Ĥ are then
preceeded by a subscript Ĥ to mark that transfer.

No, the Ĥ is a subscript to the ⊢.  He explains that in an earlier
chapter of the book.  (And never mentions anything about any business
of marking the code transfer like that.)

Let's see...  so in my copy (5th Edition) it's in Section 9.1 "The
Standard Turing Machine", just after Example 9.4.  There are plenty of
following examples of the machine subscript used that way.

There is no need to list the machine on the ⊢ symbol, as a given
chart is all of just one machine.

I suppose he considered that within the context of his HP proof there
were 3 machines (H, H', H^) so it would be worth qualifying the
machine.  Personally I agree that in each statement in the proof, the
machine context is obvious enough..  And for sure on this forum the
machine in question is generally perfectly clear.

This means the claim of the duplicate q0 state is wrong, as one is
the state q0, as the starting state of M/Ĥ, and the other state
thought to be also q0 is actually Ĥq0, (with Ĥ a pre-subscript)
indicating the q0 state of H that has been copied into Ĥ

..if your reading were correct..

Using dots instead of subscripts, and brackets instead of W prefix
can be a help for readability.

With that, the starting state of Ĥ is q0, but the copied starting
start of H would be Ĥ.q0 or H.q0 depending on if you are marking that
it was copied into Ĥ or from H, but either way, is distinct from q0.

But either way, the key point is that ⊢* doesn't mean "arbitrary
sequence" as in the machine can change what happens at each of the
steps, but that it is a "unspecified sequence" in that it isn't
listed, but for the given machine, the path *IS* fully defined.

Sure, no disagreement on that.  Also PO has said the notation is a
"specification" of Ĥ, which is a complete misunderstanding.  The
specification follows from Ĥ's definition earlier in the proof, and
the oft-quoted lines that PO quotes using the notation are statements
concerning the action of Ĥ taking an input of WM.

Mike.

Ĥ begins at its own start state that I call Ĥ.q0

Then Ĥ copies its input that Linz calls W_M and I call ⟨Ĥ⟩.

Then after ⊢* that Linz defines as "an arbitrary number of moves"
on page 237 Ĥ transitions to Ĥq0W_MW_M that I call Ĥ.H ⟨Ĥ⟩ ⟨Ĥ⟩.

I call this Ĥ.H because Linz specifies that this is the first
state of his original H machine (template).

Why do you call it the origianl H machine (template).

H is a Turing Machine, as required to be a decider.

At Ĥ.H should be the implementaton of the copy of the algorithm that
build H.

That algorithm is a precise detailed step-by-step set of operations, and
thus the ⊢* are not "arbitrary", just not specified here, but are
EXACTLY the sequence specified by that algorithm of H, and thus for a
given H, an exact sequence.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Am Sat, 06 Sep 2025 12:51:25 -0500 schrieb olcott:

On 9/5/2025 7:51 PM, Kaz Kylheku wrote:

On 2025-09-05, olcott <polcott333@gmail.com> wrote:

Its caller is a directly executing process that no C function can
possibly see.

Of course a function cannot look for its caller. There is no such
thing; pure functions do not have a caller.

In other words it is impossible to write a pure function in C that is
called by main()?

Are you now saying that functions *can* "look for their caller"?
--
Am Sat, 20 Jul 2024 12:35:31 +0000 schrieb WM in sci.math:
It is not guaranteed that n+1 exists for every n.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/6/2025 4:56 PM, joes wrote:

Am Sat, 06 Sep 2025 12:51:25 -0500 schrieb olcott:

On 9/5/2025 7:51 PM, Kaz Kylheku wrote:

On 2025-09-05, olcott <polcott333@gmail.com> wrote:

Its caller is a directly executing process that no C function can
possibly see.

Of course a function cannot look for its caller. There is no such
thing; pure functions do not have a caller.

In other words it is impossible to write a pure function in C that is
called by main()?

Are you now saying that functions *can* "look for their caller"?

No. I am correcting his mistake:
"pure functions do not have a caller."
Sure they do or pure functions cannot exist in C that always
have at least main() as their caller.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 06/09/2025 19:35, Richard Damon wrote:

On 9/6/25 1:55 PM, Mike Terry wrote:

On 06/09/2025 13:56, Richard Damon wrote:

On 9/5/25 11:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

On 9/5/25 1:06 PM, olcott wrote:

On 9/5/2025 11:01 AM, André G. Isaak wrote:

On 2025-09-05 08:16, olcott wrote:

On 9/4/2025 10:06 PM, André G. Isaak wrote:

On 2025-09-04 20:57, olcott wrote:

M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.∞  // accept state >>>>>>>>>> M.q0 ⟨M⟩ ⊢* M.H ⟨M⟩ ⟨M⟩ ⊢* M.qn // reject state >>>>>>>>>

That's your syntax. It's not "more conventional". It's just muddled. >>>>>>>>>

As I already established Sipser, Kozen and Hofcroft
all use M for Turing machine M.

It's not your use of M that I am objecting to. It is your use of M.H. >>>>>>>

Linz does this same thing in an objectively
incorrect way by giving Ĥ two different start states.
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞,
if M applied to WM halts, and
    q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ y1 qn y2,
if M applied to WM does not halt.

And what is incorrect about this?

Ĥq0  is just the name in M for the state of the beginning of the algorithm of H, the state that
was q0 in H.

That's not what Linz's notation means.  Part of the problem is reflecting the Linz typesetting
here in these posts.  In the expression
      q0 WM ⊢* Ĥq0 WM WM ⊢* Ĥ∞

both the * and Ĥ are joined to the ⊢ symbol.  * is a superscript,
indicating some unspecified number of ⊢ steps.  Ĥ is a subscript to the > ⊢ indicating the

machine performing the stepping, i.e. it says the

unspecified number of steps are according to Ĥ's state transition rules.  Hmm, also the WM is
actually W subscripted by M.  (Both W and M separately already having their own meanings in the
proof.)

Representing the subscript relationship in these posts is awkward. Traditionally posters have
used _ (underscore) for this, in which case Linz's notion would be properly quoted here as

   q_0 W_M  ⊢*_Ĥ  q_0 W_M W_M  ⊢*_Ĥ  ∞

(Linz's notation omits the spaces, because the typesetting is (not great, but) better than in
these usenet posts.)  Or we might get away with

   q0 WM  ⊢*Ĥ  q0 WM WM  ⊢*Ĥ  ∞

if we say we'll always put spaces between separate tokens, so it will be clear e.g. that WM is W
subscripted by M, not W followed by M.

Or just assuming the machine Ĥ is understood through context, so it becomes just

   q0 WM  ⊢*  q0 WM WM  ⊢*  ∞

Anyway, Ĥq0 is not the compound symbol you're suggesting...  And it does seem Linz has used
state q0 twice with different meanings!  :( Well, it is perfectly obvious how that should be
fixed - an erratum sure, but hardly a problem with the proof itself.

(Yeah, the notation is a bit of a mess for representing in a pure character string format.
Personally I think using qualified state labels such as H.q0 is reasonable, and also using <M>
to indicate the string description of M seems clearer than WM or W_M.  But such things need
explaining...)

Mike.

That's not how I read his notation.

For each state in the process, we list the state name, possible preceeded and followed by the
tape contents with the state name being tape head pointer.

Right.

Listing of states of H that have been copied into Ĥ are then preceeded by a subscript Ĥ to mark
that transfer.

No, the Ĥ is a subscript to the ⊢.  He explains that in an earlier chapter of the book.  (And
never mentions anything about any business of marking the code transfer like that.)

Let's see...  so in my copy (5th Edition) it's in Section 9.1 "The Standard Turing Machine", just
after Example 9.4.  There are plenty of following examples of the machine subscript used that way.

Ok, I don't have the book, but going on the material presented.

It seems to be a bad notation, as you KNOW what machine you are tracing from the states being named.

There is no need to list the machine on the ⊢ symbol, as a given chart is all of just one machine.

I suppose he considered that within the context of his HP proof there were 3 machines (H, H', H^)
so it would be worth qualifying the machine.  Personally I agree that in each statement in the
proof, the machine context is obvious enough..  And for sure on this forum the machine in question
is generally perfectly clear.

but it does mean his H^ now has two states named q0

A proper Erratum. Sadly Linz died last year, so there is never going to be a 6th edition where such
errors would typically be tidied up (if some reader reports them)

This means the claim of the duplicate q0 state is wrong, as one is the state q0, as the starting
state of M/Ĥ, and the other state thought to be also q0 is actually Ĥq0, (with Ĥ a pre-subscript)
indicating the q0 state of H that has been copied into Ĥ

..if your reading were correct..

and not doing something to change the name means the example is incorrect.

That's why PO introduced dotted label names, to get around that sort of issue.

Using dots instead of subscripts, and brackets instead of W prefix can be a help for readability.

With that, the starting state of Ĥ is q0, but the copied starting start of H would be Ĥ.q0 or
H.q0 depending on if you are marking that it was copied into Ĥ or from H, but either way, is
distinct from q0.

But either way, the key point is that ⊢* doesn't mean "arbitrary sequence" as in the machine can
change what happens at each of the steps, but that it is a "unspecified sequence" in that it
isn't listed, but for the given machine, the path *IS* fully defined.

Sure, no disagreement on that.  Also PO has said the notation is a "specification" of Ĥ, which is
a complete misunderstanding.  The specification follows from Ĥ's definition earlier in the proof,
and the oft-quoted lines that PO quotes using the notation are statements concerning the action of
Ĥ taking an input of WM.

Mike.

Just more of POs not understanding the basic principles of what he is reading.

Seems that it doesn't help that he chose a source that isn't as good as it could be.

Generally, I'd say the Linz book is a much better book for PO than the Sipser book. Linz makes a
point in the Preface that he is writing for students of computer science who don't necessarily have
a solid maths background. So his emphasis is on teaching, rather than on completely formal
correctness. (Sipser is terse, and more suited for maths students, I'd say.)

But given Linz's aims, I'd say his treatment of the HP proof is not great. It is rather lacking in
motivational explanations of what's going on. It just defines H^ in terms of H, and more or less
just claims (albeit correctly) that this generates a contradiction.

Does Linz never describe how to form a representation of a machine, or s thus just a blind spot of
Peter's that he can't allow the input to actualy represent the machine it is from?

Linz proposes a scheme to represent TMs and tapes earlier in the book, probably when he talks about
UTMs. It is some kind of binary representation as I recall. So any problems going on from that are
PO's.

That is an abstraction that seems to be beyond his ability.

Yes, and there is the problem that the TM-description covers the full machine. I.e. in DD()'s case
it would be something like a binary string consisting of all the object code of
DD+HHH+Init_Halts_HH+Init_slave_state0+Decide_Halting_HH+Needs_To_Be_Aborted_HH+Needs_To_Be_Aborted_Trace_HH,
plus all the global constants used by those routines (all tied to their memory addresses as part of
the description). PO I'm sure thinks it's just the object code bytes of function DD. His "short
cut" of passing simply a pointer to DD obscures (to PO at least) this mistake he makes.

Mike.










--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 06/09/2025 19:43, olcott wrote:

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional infinite loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

Idiot.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/7/2025 10:53 AM, Mike Terry wrote:

On 06/09/2025 19:43, olcott wrote:

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional infinite >>> loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

Idiot.

It *is* short-hand for the cycle
between qa and qb on the top of page 319. // typo
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 09/09/2025 00:38, olcott wrote:

On 9/7/2025 10:53 AM, Mike Terry wrote:

On 06/09/2025 19:43, olcott wrote:

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional infinite loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

Idiot.

It *is* short-hand for the cycle
between qa and qb on the top of page 319. // typo

We were talking about what the ∞ symbol *means* within the notation, not "what it applied to in one
specific expression".

Linz - Following Definition 9.2

Example 9.3 shows the possibility that a Turing machine will never
halt, proceeding in an endless loop from which it cannot escape. This
situation plays a fundamental role in the discussion of Turing machines,
so we use a special notation for it. We will represent it by indicating
that, starting from the initial configuration x1 q x2, the machine goes
into a loop and never halts.

x1 q x2 ⊢* ∞

So what I said was in no way *COUNTER FACTUAL*

Mike.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-08, olcott <polcott333@gmail.com> wrote:

On 9/7/2025 10:53 AM, Mike Terry wrote:

On 06/09/2025 19:43, olcott wrote:

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional infinite >>>> loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

Idiot.

It *is* short-hand for the cycle
between qa and qb on the top of page 319. // typo

Linz's work defends the Halting Theorem. I find it mind-boggling that
despite thinking that this Theorem is invalid, you keep referencing that
same author in /defense/ of your crazy ideas.

If that author is wrong, and you are right, how can he be of use?
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-09-03 15:01:35 +0000, olcott said:

On 9/3/2025 9:47 AM, Richard Heathfield wrote:

On 03/09/2025 15:33, olcott wrote:

On 9/3/2025 9:30 AM, Richard Heathfield wrote:

On 03/09/2025 15:24, olcott wrote:

As long as HHH handles all of the instances of the
"do the opposite" code

It doesn't. It ignores it.

Ignoring isn't handling.

Unreachable code must be ignored.

Reachable code must not be ignored.

Dishonestly changing my words and then rebutting
the changed words.

You are lying. Your words were quoted as you said them, with no
change.

If the x86 can reach it, so can you.

--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 2025-08-31 16:06:14 +0000, olcott said:

On 8/31/2025 4:27 AM, Mikko wrote:

On 2025-08-31 04:08:59 +0000, olcott said:

On 8/30/2025 10:56 PM, Kaz Kylheku wrote:

On 2025-08-31, olcott <polcott333@gmail.com> wrote:

On 8/30/2025 10:24 PM, Kaz Kylheku wrote:

On 2025-08-30, olcott <polcott333@gmail.com> wrote:

On 8/30/2025 2:49 PM, Kaz Kylheku wrote:

On 2025-08-30, olcott <polcott333@gmail.com> wrote:>>

Using the notion of naming conventions proposed by Kaz


HHH(DD).exe is only being asked about DD.sim1.
HHH cannot be asked about DD.exe

If you move the distinguishing suffixes outside of the expression, >>>>>>>> it becomes ambiguous. Does  A(B).sim mean that B is simulated >>>>>>>> or A and B are both simulated?

I think you want:

// with static fuses being used:

DD_exe is executed
DD_exe calls HHH_exe(DD_exe)

That has always been impossible
HHH has never ever been asked about
the executing process of its caller.

HHH does not have a caller. HHH is a halting decider that someone
proposed.

DD was developed after HHH to show that it's broken;
but HHH was already broken before that.

DD may be developed using a clean-room implementation of the HHH
algorithm; it doesn't call back into the decider that is operating on it >>>>>> or anything like that.

That's just unnecessary embellishments that you have added.

HHH has always been asked about the behavior
specified by its input finite string of x86 code.

Sure; any string whatsoever.

WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA
WE ARE ASSUMING NO STATIC DATA

Then we have only one HHH and one DD in the system; it is not possible >>>>>> to claim that HHH decides some DD other than that one DD.

An infinite number of HHH/DD pairs is decided this way.

There is only one HHH/DD pair, because HHH and DD must refer to specific >>>> algorithms.

Other pairs must use at least one name that is different, like
HHH1/DD or HHH/DD1 or HH1/DD1, HH2/DD7, ...

<Input to LLM systems>
Simulating Termination Analyzer HHH correctly simulates its input until: >>>>> (a) Detects a non-terminating behavior pattern:
abort simulation and return 0.

That's readily contradicted by the diagonal program which
integrates a clean-room implementation of the HHH algorthm,
calls it on itself, obtains the zero, and promptly terminates.

Five LLM systems were smart enough to see this
and return the correct value for HHH so we

Everyone you've discussed with here is also smart enough
to see that a given DD will terminate or not, and identify
the correct halting status.

You still don't get it that HHH is only supposed to
report in the infinitely recursive behavior that its
input specifies and it not supposed to report on the
behavior of its caller: DD called from main().

Your suppositions make HHH irrelevant to the halting problem
mentioned on the subject line.

When the HP requires a decider to report on its
caller that contradicts the definition of Turing
machine deciders that only report on their inputs.

A requirement is not a truth bearer and therefore cannot contradict.
--
Mikko

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/8/2025 7:42 PM, Mike Terry wrote:

On 09/09/2025 00:38, olcott wrote:

On 9/7/2025 10:53 AM, Mike Terry wrote:

On 06/09/2025 19:43, olcott wrote:

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional
infinite loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

Idiot.

It *is* short-hand for the cycle
between qa and qb on the top of page 319. // typo

We were talking about what the ∞ symbol *means* within the notation, not "what it applied to in one specific expression".

∞ is specifically short-hand for the cycle between
states (qa) and (qb) on the top of page 319.
Its only purpose is to make the notation more concise.

Linz - Following Definition 9.2

   Example 9.3 shows the possibility that a Turing machine will never
   halt, proceeding in an endless loop from which it cannot escape. This
   situation plays a fundamental role in the discussion of Turing machines,
   so we use a special notation for it.  We will represent it by indicating
   that, starting from the initial configuration x1 q x2, the machine goes
   into a loop and never halts.

           x1 q x2 ⊢* ∞

So what I said was in no way *COUNTER FACTUAL*

Mike.

--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

On 9/8/2025 9:34 PM, Kaz Kylheku wrote:

On 2025-09-08, olcott <polcott333@gmail.com> wrote:

On 9/7/2025 10:53 AM, Mike Terry wrote:

On 06/09/2025 19:43, olcott wrote:

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional infinite >>>>> loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

Idiot.

It *is* short-hand for the cycle
between qa and qb on the top of page 319. // typo

Linz's work defends the Halting Theorem. I find it mind-boggling that
despite thinking that this Theorem is invalid, you keep referencing that
same author in /defense/ of your crazy ideas.

If that author is wrong, and you are right, how can he be of use?

The Linz proof is the best of all proofs because
he boils down the essence of the conventional
halting problem proofs down to a template having
explicit state transitions for its key element.

Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞ // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state

*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

When we assume that embedded_H is based on a UTM
that is a simulating halt decider we can see that
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H never
reaches its own simulated final halt state of ⟨Ĥ.qn⟩

When embedded_H computes the mapping from its input
to the ACTUAL BEHAVIOR ACTUALLY SPECIFIED BY THIS
INPUT (the semantic property of the finite string)
this makes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn correct.
--
Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.theory

Op 09.sep.2025 om 17:16 schreef olcott:

On 9/8/2025 9:34 PM, Kaz Kylheku wrote:

On 2025-09-08, olcott <polcott333@gmail.com> wrote:

On 9/7/2025 10:53 AM, Mike Terry wrote:

On 06/09/2025 19:43, olcott wrote:

On 9/6/2025 1:15 PM, Mike Terry wrote:

On 06/09/2025 15:18, olcott wrote:

On 9/5/2025 10:25 PM, Mike Terry wrote:

On 05/09/2025 19:46, Richard Damon wrote:

⟨M⟩ Turing machine description of M.
⊢* an arbitrary number of moves where a
move is the execution of one TM instruction.
∞ the traditional infinite loop at the halt state.

The ∞ means "computation never terminates", not "traditional infinite >>>>>> loop at the halt state".

*COUNTER FACTUAL* It literally means the directed
graph cycle between qa and qb on the top of page 339.

Idiot.

It *is* short-hand for the cycle
between qa and qb on the top of page 319. // typo

Linz's work defends the Halting Theorem. I find it mind-boggling that
despite thinking that this Theorem is invalid, you keep referencing that
same author in /defense/ of your crazy ideas.

If that author is wrong, and you are right, how can he be of use?

The Linz proof is the best of all proofs because
he boils down the essence of the conventional
halting problem proofs down to a template having
explicit state transitions for its key element.

Turing Machine Linz Ĥ applied to its own machine description ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞  // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state

*Repeats until aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩

When we assume that embedded_H is based on a UTM
that is a simulating halt decider we can see that
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by Ĥ.embedded_H never
reaches its own simulated final halt state of ⟨Ĥ.qn⟩

Not being able to reach the final halt state because of a premature
abort is not evidence that the input specified a non-terminating
program. It is only a failure of the decider to see the specified specification.

When embedded_H computes the mapping from its input
to the ACTUAL BEHAVIOR ACTUALLY SPECIFIED BY THIS
INPUT (the semantic property of the finite string)
this makes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ transition to Ĥ.qn correct.

The actual behaviour of the aborting H is a halting program. If H does
cannot reach that part of the specification, it fails. That does not
change the specification.
The input is not a hypothetical program that does not abort.
The ACTUAL BEHAVIOUR ACTUALLY SPECIFIED BY THIS INPUT (the semantic
property of the finite string) is a halting program, whether the decider
can see that or not.
Making the decider blind for the specification does not change the specification.

--- Synchronet 3.21a-Linux NewsLink 1.2