From Newsgroup: comp.ai.philosophy

On 10/16/2026 3:27 AM, Mikko wrote:

On 10/10/2026 22:57, olcott wrote:

On 10/10/2026 3:31 AM, Mikko wrote:

On 09/10/2026 14:40, olcott wrote:

On 10/9/2026 3:18 AM, Mikko wrote:

On 07/10/2026 15:25, polcott wrote:

On 10/7/2026 5:40 AM, Mikko wrote:

On 02/10/2026 15:28, olcott wrote:

On 10/1/2026 10:05 PM, dart200 wrote:

On 10/1/26 5:28 PM, Chris M. Thomasson wrote:

On 10/1/2026 3:54 PM, dart200 wrote:
[...]

Are you saying that the halting problem is not solvable? If >>>>>>>>>> so, so what?

it is solvable for an enumerable set of machines that includes >>>>>>>>> all possible output sequences, it is not solvable for all
possible machines

The key mistake of the halting theorem is that
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()

No, it isn't. The halting problem says nothing about "DD()" or
"main()".
The halting problem asks "How can one determine whether a
computation
halts?"

Here is the same thing from Linz where H and Ĥ.embedded_H are
also based on UTM simulation of their inputs.

*From the bottom of page 319 has been adapted to this*

Earlier on that page Linz says: "Simply stated, the problem is: given >>>>> the description of a Turing machine M and an input w, does M, when
started in the initial configuration qow, perform a computation that >>>>> eventually halts?"

At the bottom of the page, continuing to the next page, is a formal
definition of the solution of the halting problem, which Linz defines >>>>> as a Turing machine.

https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state

There is no "embedded_H" in Linz's definition.

<Linz text>
 From H' we construct another Turing machine Ĥ.

That is later in the text, not in the definition 12.1, so irrelevant
to this discussion.

I am ONLY talking about the Linz machine that totally
implements the Halting Problem counter-example input.

You are trying to cheat with a switch of topid and a pretension that
what was said abaut one topic be true about the other.

The topic was the definition of the "halting problem" and in particular
how Linz defines it. As long as you don't understand or can't express
that there is no point to go further.

I am referring to the actual Halting Problem proof
where the input to Ĥ is applied to its own source
code ⟨Ĥ⟩ that has been defined to do the opposite of
whatever halt status that it determines.

*From the bottom of page 319 original code*
q0 Wm Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ.∞ // accept state
q0 Wm Wm ⊢* Ĥq0 Wm Wm ⊢* Ĥ.qn // reject state

https://liarparadox.org/Peter_Linz_HP(Pages_318-319).pdf

(1) Linz makes the mistake of having two start states
q0 and Ĥq0.

(2) It is totally unclear that Ĥq0 refers an embedded
copy of his own H machine thus "Ĥ.embedded_H" is
a much clearer way of saying that.

Page 319 top and middle
Next, we modify H to produce a Turing machine H'
From H' we construct another Turing machine Ĥ.

(3) The distinct case of machine Ĥ being applied to
its own source code is clearer when encoded as
"Ĥ.q0 ⟨Ĥ⟩" instead of "q0 Wm Wm"

*the bottom of page 319 has been adapted to this*
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state

⟨Ĥ⟩ more conventionally shows that Ĥ is taking its
own finite string machine description as its input.

The term "machine description" is misleading it allows
people to assume a level of indirect reference that does
not actually exist so I call it the source code of Ĥ.

The source code input to embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ "specifies"
rather than the more vague term of "describes" a unique
sequence of state transitions.

When embedded_H is a UTM based simulating halt decider then

*Keeps repeating unless aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
--
Copyright 2026 Olcott

*Succinct refutation of the Halting Theorem* https://github.com/plolcott/x86utm/blob/master/README.md


The essence of computation is applying finite
string transformations to finite string inputs
to derive outputs. // paraphrase of Emil Post

My 28 year goal has been to make
"true on the basis of meaning expressed in language"
reliably computable for the entire body of general knowledge.
The complete structure of this system is now defined.

The entire body of knowledge expressed in language is
comprised of two types of relations between finite strings:
(a) *Axioms* Expressions of language that are stipulated to be true.

My system bridges the analytic/synthetic distinction by
expressly encoding all empirical "atomic facts" in a formal
language such as CycL of the Cyc project.

(b) *Inference Rules* Expressions of language that are semantically
entailed syntactically from (a) and/or (b).
--- Synchronet 3.22a-Linux NewsLink 1.2