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:The key mistake of the halting theorem is that
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 >>>
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*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
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.
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 Ĥ.
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:The key mistake of the halting theorem is that
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 >>>
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*
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.
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.
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.
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.
Axiom 1
--- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of
finite string transformation rules to finite string
inputs to derive any and all outputs.
Axiom 2
Computation requires correct rather than
arbitrary finite string transformations.
The brand new key insight that I had into the
foundations of computation is the notion of
{correct finite string transformations} as
opposed to and contrast with {arbitrary finite
string transformations}.
If we need to know the sum of 2 + 3 there seems
to be only a single sequence of finite string
transformation rules that derive this within
arithmetic operations on the integer type. This
is one concrete example of how computation is
limited to correct finite string transformations.
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.
Good. Then we have finally isolated the disagreement completely.
You now explicitly require not merely:
H's answer must be correct.
but:
H's answer must be obtained through a particular
semantically approved sequence of inference steps.
You even say:
"It cannot even be a correct guess."
That is an EXTRA requirement.
Computability theory normally asks whether a computation computes the correct mapping:
input -> output
It does not additionally require every intermediate inference step to constitute a proof of the semantic fact represented by the output.
For example, if two programs return exactly the same correct answer on
every input, they compute the same function even if one uses simulation,
one uses theorem proving, and one uses a lookup table.
So your logical target is now extremely precise:
You must prove that semantic correctness of the OUTPUT
requires semantic correctness, in your special sense,
of the particular INFERENCE PATH used to obtain it.
Neither Post's finite-string model nor operational semantics gives you
that requirement.
You have added it.
And this matters far beyond DD: without that new requirement, your distinction between HHH(DD)==0 and HHH1(DD)==1 cannot redefine the
halting predicate.
So before moving to the much larger goal of making
"true on the basis of meaning expressed in language"
computable, this much smaller proposition needs a formal proof.
Otherwise "correct transformation" is simply being defined as "a transformation following the semantics
I require",
and then used to--
prove that only those transformations are correct.
That is circular.
Your `sum` example makes the disagreement even clearer.
I agree that
int sum(int x, int y) { return 5; }
does NOT compute integer addition on its full domain.
But now consider:
int add(int x, int y) {
return addition_table[x][y];
}
where `addition_table` contains the correct sum for every pair in the
finite domain.
This computes exactly the same mathematical function as:
return x + y;
Yet its runtime transformations are merely:
read x,y
index table
retrieve value
return value
It does not derive the result by performing the arithmetic inference
2 + 3 = 5.
And we must distinguish TWO different computations here:
A. the computation or reasoning that CONSTRUCTED the table
B. the computation add(x,y) that USES the table
Perhaps A calculated every entry using arithmetic, theorem proving, a
human mathematician, or something else entirely.
That is irrelevant to what B computes.
Once the table exists, B computes addition without reproducing,
containing, or even knowing the derivation by which the table was constructed.
Indeed, two identical copies of B compute exactly the same function even
if their tables were independently produced by completely different processes.
So saying:
"the semantic inference was off-loaded"
actually concedes the distinction.
Yes — it was performed ELSEWHERE.
Therefore it is not an inference step of the computation B whose
behavior we are classifying.
If you nevertheless say B does NOT compute addition because the semantic derivation occurred elsewhere, then you have changed the standard
meaning of "computes a function".
And your PI analogy illustrates the same distinction.
The value of PI does not depend upon HOW somebody computes it. Different algorithms can derive the same digits through radically different transformations.
So I grant:
the output must satisfy the semantic specification.
What I do NOT grant is:
the computation producing that output must itself
contain a semantic derivation proving that output.
That additional requirement does not follow merely by combining finite- string computation with operational semantics.--
You keep asserting that it has "always been required".
But THAT assertion is exactly the proposition requiring proof.
There is an even more fundamental problem with saying that a lookup
table "computes no mapping".
Go down to the hardware implementation of arithmetic itself.
A binary half-adder implements exactly this finite mapping:
inputs outputs
A B SUM CARRY
0 0 -> 0 0
0 1 -> 1 0
1 0 -> 1 0
1 1 -> 0 1
A full adder does the same thing with an additional carry input, giving eight cases.
Now this can be implemented with logic gates.
But it can ALSO be implemented literally as a tiny ROM:
address bits = A,B
stored bits = SUM,CARRY
Then the physical operation is simply:
apply address -> retrieve stored bits
In other words, a hardware lookup table.
Nothing inside that ROM performs an additional semantic proof that
1 + 1 = 10 binary.
Yet by composing these elementary mappings we construct an arithmetic
unit that computes addition.
So if you maintain that lookup-table B "computes no mapping", where
exactly does the REAL computation of addition begin?
You cannot answer "some earlier process constructed the table", because
the same issue recurs at the lowest hardware level.
Ultimately the machine consists of physical mechanisms implementing elementary mappings.
We call the resulting process "addition" because the composition of
those mappings realizes the mathematical addition function.
The hardware does not additionally prove that its output is semantically entailed by arithmetic.
This exposes the distinction I have been making:
SEMANTICS specifies the mapping we require.
COMPUTATION implements that mapping.
PROOF establishes that the implementation
satisfies the specification.
Those are three different things.
Your argument is effectively requiring COMPUTATION itself to contain PROOF.
That is not something you get from Post plus operational semantics.
And if a ROM implementing the truth table above "computes no mapping",
then your definition has the remarkable consequence that the elementary components from which actual arithmetic computers are constructed do not compute their mappings either.
Your argument is effectively requiring COMPUTATION itself to contain PROOF.
Yes.
Peter,
This actually clarifies the disagreement considerably.
I wrote:
Your argument is effectively requiring COMPUTATION itself to contain
PROOF.
and you answered:
Yes.
Good. Then this is now the precise point that needs justification.
In standard computability theory, a machine transition
C -> C'
is not required to be a semantic entailment
C |= C'
nor a proof step from stipulated axioms.
It is simply a transition specified by the machine's transition function.
Of course one can DESIGN a computation whose transitions encode valid inference steps. A theorem prover does exactly that. But it does not
follow that every computation must be such a proof.
Your arithmetic example makes the problem especially clear.
Consider two 8-bit adders.
A is constructed conventionally from gates and full adders.
B is a ROM containing all 65536 mappings
(x,y) -> (x+y) mod 256.
For every possible input,
A(x,y) = B(x,y).
Now either B computes addition or it does not.
If it does, then lookup tables can compute mappings, which was my point.
If it does not, then you need to explain why two machines implementing exactly the same input/output function differ as to whether they
"compute" that function.
And appealing to "stipulated axiom finite strings" does not solve this.
I can simply stipulate the 65536 ROM entries as finite-string axioms:
ADD(0,0)=0
ADD(0,1)=1
...
ADD(255,255)=254
The ROM lookup is then direct application of one of your stipulated
finite strings.
If those entries must themselves be derived from something else before
their use counts as computation, then they were not foundational
stipulated axioms after all, and the same question merely moves back one level.
So we have finally isolated the issue.
You are defining computation to require syntactically represented
semantic entailment from stipulated axioms.
That is a perfectly possible definition of a particular kind of formal inference process.
What has not been established is that this is the definition of
computation used by Post, Turing, or standard computability theory.
Saying
"that is the way ... it has always worked"
does not establish that.
Please identify the definition or theorem in Post, Turing, or standard operational semantics from which the following implication follows:
valid computational transition
=>
syntactically represented semantic entailment
from stipulated axiom finite strings.
That implication is now the entire issue.
Without it, your argument does not refute the halting theorem. It
changes the definition of computation and then proves a result about the changed definition.
BTW, have you read Greg Egan's novels and short stories?
It is not. It is my improvement of what they said built
on top of my generic paraphrase of Post.
Random answers to specific questions are never correct.
Table look up is not maximum algorithm compression
Even the category of a counter-example cannot possibly exist.
On 10/16/2026 10:43 AM, Python wrote:But then
Your argument is effectively requiring COMPUTATION itself to contain
PROOF.
Yes that is the way that semantic entailment specified
syntactically on the basis of a set of stipulated axiom
finite strings has always worked.
Op 16.okt.2026 om 18:25 schreef olcott:
On 10/16/2026 10:43 AM, Python wrote:
But thenYour argument is effectively requiring COMPUTATION itself to contain
PROOF.
Yes that is the way that semantic entailment specified
syntactically on the basis of a set of stipulated axiom
finite strings has always worked.
int sum (int x, int y) { return x+y; }
does not contain a proof.
A proof start from the definitions and axioms. In this case the
definition of natural numbers.
For a complete proof of sum(5,3) we then have decompose 5 as ((((1+1)+1)+1)+1) (this follows from the definition of 5) and 3 as
((1+1)+1) (from the definition of 3), then use commutation rules to transform this into (((((((1+1)+1)+1)+1)+1)+1)+1) and transform that
into 8 (from the definition of 8).
That is not how the computer computes 5+3.
So, using the computer's adder, which uses a very different algorithm,
is not a proof and according to Olcott it is not a correct computation.
Using summation rules learned at school is not a proof.
I guess that we have to construe the circuitry as
equivalent to a proof.
It is not. It is my improvement of what they said built
on top of my generic paraphrase of Post.
Then we agree on an important point: your requirement that computation consist of syntactically specified semantic entailment is not a
requirement of Post, Turing, or standard computability theory. It is a
new requirement introduced by your own theory.
That is perfectly legitimate as a research proposal, but it means that results obtained from that additional requirement do not, by themselves, overturn results about Turing computation.
There is also a problem with your new Axiom 2:
Random answers to specific questions are never correct.
Literally, that is false. If I randomly answer YES or NO to
Is 2+2=4?
I may randomly answer YES, which is correct.
What I think you mean is:
Arbitrary answers provide no guarantee of correctness.
That is true, but it does not imply:
Computation requires every transformation to be
a semantically entailed transformation.
Those are very different propositions.
The ROM example exposes the difference.
Suppose I manufacture a 16-bit-address, 8-bit-output ROM whose contents,
by sheer accident, happen to satisfy
ROM[x,y] = (x+y) mod 256
for every x,y.
No previous process computed the table. Nothing was "off-loaded." We
simply discovered afterward that this physical device implements the 8-
bit addition function.
When presented with (23,42), it returns 65.
Does this device compute the 8-bit addition function?
If not, then your definition of "computes" depends not merely on the machine's structure and behavior, but on the causal history by which its contents came to exist.
That would be a radically different concept from computation in computability theory.
Also:
Table look up is not maximum algorithm compression
Agreed, but that is a different question.
Whether an implementation computes a function and whether it is a
maximally compressed algorithm for that function are not equivalent questions.
Finally:
Even the category of a counter-example cannot possibly exist.
MECE cannot establish that.
MECE can describe how you partition a domain. It cannot prove that your premises are true or that your proposed categories correctly model the phenomenon under investigation.
Indeed, if a theory concludes in advance that the category of counterexamples "cannot possibly exist,"
that is precisely where I would
look hardest for an unstated assumption.
So I think we have made substantial progress.
We no longer need to debate whether Post requires your notion of
semantic computation: you have now explicitly said that he does not.
The question is therefore much simpler:
Can you derive
computation
=>
correct semantic entailment from stipulated axioms
rather than simply defining "computation" to mean that?
Because if it is a definition, you have introduced a new class of
processes.
If it is a theorem about computation generally, it needs a proof
independent of that definition.
BTW, since you mentioned that you had never heard of Greg Egan, I think--
you might genuinely enjoy some of his work. He is unusually interested
in exactly the boundary between computation, implementation, semantics, identity and physical realization that we keep running into here.
A few suggestions, roughly in the order I would recommend them to you:
* **"Learning to Be Me"** (short story, in *Axiomatic*) — probably the most directly relevant. People have neural "jewels" implanted that learn
to reproduce their brains' input/output behavior until they can replace
the biological brain. It raises almost exactly the question: when does reproducing a mapping become reproducing the process or person that generated it?
* **Permutation City** — simulated minds, computational identity, and
the question of what it means for a computation to be physically instantiated. If two implementations realize the same computational structure, what makes one of them "real"? This is probably the Egan
novel most relevant to our disagreement.
* **"Axiomatic"** (short story) — asks what happens when apparently foundational beliefs and values can themselves be technologically
modified. Given your interest in foundational axioms, you may appreciate
the joke implicit in the title.
* **Diaspora** — begins with the creation of an artificial mind and then goes much further into questions of mathematical description, physical reality, simulated environments and post-human intelligence.
* **"Luminous"** — especially relevant if you are interested in the relationship between formal systems, mathematical truth and physical computation. It plays with the rather disturbing idea that mathematics itself might not be as implementation-independent as we normally assume.
* **"Oracle"** — deals with artificial intelligence, computability, mathematics and an alternate-history confrontation over the intellectual consequences of advanced computation.
* **"Singleton"** — explores quantum mechanics, computation and personal identity, including the consequences of trying to construct an
artificial intelligence.
* **"Crystal Nights"** — artificial life is evolved inside a
computational environment, raising the question of whether entities generated by a computational process acquire meanings, purposes and interests that were not explicitly supplied by their programmers.
If you only try three, I would suggest:
Learning to Be Me
Permutation City
Luminous
Egan is a programmer as well as a science-fiction writer, and unlike a
great deal of SF that merely uses computation as decoration, he tends to take the computational and mathematical premises seriously and then
follow their consequences somewhere uncomfortable.
I suspect you will disagree with him quite a lot, which is one reason I think you might find him interesting.
Peter,
I guess that we have to construe the circuitry as
equivalent to a proof.
I think that sentence exposes exactly the problem.
Equivalent to WHAT proof, in WHAT formal system?
An adder circuit implements a function. We can construct a proof that
the circuit implements addition correctly, but the circuit and that
proof are not the same thing.
For example, let C be an 8-bit adder circuit. We may prove:
for all x,y:
C(x,y) = (x+y) mod 256
Here we have three distinct objects:
specification: (x,y) -> (x+y) mod 256
implementation: C
proof: C satisfies the specification
Calling C itself "equivalent to a proof" simply collapses those three distinctions by definition.
And it immediately brings us back to the ROM problem.
Suppose C is implemented with gates.
Now synthesize exactly the same Boolean function into LUTs.
Or implement it as a ROM containing its truth table.
All three devices implement exactly the same mapping.
So if the gate circuit is "equivalent to a proof", is the LUT
implementation also equivalent to a proof?
Is the ROM?
If not, precisely what proof-theoretic property disappeared during the transformation?
This is not merely hypothetical. FPGA LUTs are literally small stored
truth tables used to implement Boolean functions. Logic synthesis
routinely moves between Boolean descriptions and LUT implementations.
So I think "the circuitry is equivalent to a proof" does not solve the problem. It makes the circularity more visible:
Why is this a computation?
Because it embodies a proof.
Why does it embody a proof?
Because it correctly computes the function.
Correctness of an implementation can be PROVED.
It does not follow that the implementation IS a proof.
A CPU executing
return x + y;
does not have to prove arithmetic before it can add x and y.
We may have to prove that the CPU's adder is correct.--
That is our proof about the computation, not the computation's proof of itself.
If we have no way to determine whether or not
X is true then X is necessarily outside of the
body of knowledge, thus outside of the domain
of my system.
Peter,
I think your latest reply reveals a very important change in the subject
of the discussion.
You wrote:
Sheer accident provides zero basis for knowledge.
My system's domain is general knowledge expressed
as relations between finite strings.
But I did not ask whether the accidental ROM provides a basis for
KNOWLEDGE.
I asked whether it COMPUTES the function.
Those are different questions.
Suppose the ROM happens to satisfy
ROM[x,y] = (x+y) mod 256
for every possible input.
Then there are at least three separate questions:
1. Does the device implement the addition mapping?
2. Do we know that it implements the addition mapping?
3. Can we prove that it implements the addition mapping?
The answer to (1) can be yes while the answers to (2) and (3) are no.
Indeed, that was precisely the purpose of the accidental-ROM example.
You replied that accident provides no basis for knowledge.
Agreed.
But that answers (2), not (1).
This also explains why I don't think the Prawitz reference establishes
what you need.
Proof-theoretic semantics is indeed concerned with explaining meaning in terms of proof, and Prawitz discusses the connection between knowing
that a mathematical sentence is true and having a proof of it.
But that is an epistemological/semantic claim about mathematical
assertion and proof.
It does not establish:
computation = justified knowledge
or:
every computational transition = semantic inference.
In fact, your latest formulation seems increasingly to describe a theory
of justified inference rather than a theory of computation.
There is another interesting development in your answer.
Previously, you said that lookup does not itself perform the computation because the computation was "off-loaded."
Now you say:
All of your table lookups are stipulated.
So my system remains correct and coherent.
and:
ROM is stipulated relations.
I am happy to accept that for the sake of argument.
But then any finite function can be represented as stipulated relations.
For a finite domain
A = {a1,...,an}
and any function f, I can stipulate
a1 -> f(a1)
a2 -> f(a2)
...
an -> f(an)
and implement exactly those stipulated relations in a ROM.
So the distinction between gate computation and ROM lookup has
disappeared from your criterion.
This also connects directly to actual computer hardware.
The same finite Boolean function can be implemented as:
gates
PLA
FPGA LUTs
ROM
and representations can be mechanically transformed between these forms.
If ROM relations qualify because they are "stipulated", then there is no longer any reason to say that computation was performed elsewhere and
merely stored in the ROM. The ROM itself implements the stipulated mapping.
More importantly, however, your present definition appears to be:
acceptable transformation =
semantically entailed transformation
OR
stipulated transformation.
That may define a formal system of justified transformations.
But why should that be identified with COMPUTATION?
Your Prawitz quotation may provide motivation for identifying
mathematical knowledge with proof under a proof-theoretic conception of meaning.
It does not provide the missing implication:
computation
=>
knowledge
=>
proof
=>
semantic entailment or stipulation.
And your final statement makes the problem especially clear:
It seems to me that the only category of proof that
I will be able to provide is self-evidence:
proven true on the basis of meaning.
I think this is exactly where we need to be extremely careful.
If your crucial foundational claim is:
Computation requires correct rather than
arbitrary finite string transformations
we need to distinguish two readings of "correct".
Reading A:
The machine actually produces the value specified
by the function.
Then the accidental ROM is correct, regardless of whether anybody knows
or can prove that it is correct.
Reading B:
The transformation is justified as correct by
semantic entailment or stipulation.
Then you have changed "correct computation" into "justified computation".
That is an epistemic notion.
And the Halting Theorem is not a theorem about what we can justify as knowledge. It is a theorem about what Turing machines can compute.
This distinction becomes especially important when you say:
Undecidability ceases to exist within this new foundation.
It may instead be that you have defined a new notion of "decision" under which only semantically justified transformations count as decisions.
If so, undecidability has not been eliminated.
You have changed the meaning of "decider".
Before claiming that the Halting Theorem has been overturned, I
therefore think you need to establish one very specific bridge:
standard Turing computation
=>
your semantically justified computation.
And "self-evidence" cannot establish that bridge if the self-evidence
comes from the meaning you have assigned to the word "computation".
Otherwise the reasoning is:
I define computation as correct justified transformation.
Therefore every computation is a correct justified transformation.
Therefore the standard theory of computation is wrong
whenever it permits transformations not satisfying my
justification criterion.
That conclusion follows from the new definition, not from a discovery
about Turing computation.
So I think we have now reached an even more fundamental question than
the ROM example:
Are you proposing a new theory of COMPUTATION,
or a new theory of JUSTIFIED KNOWLEDGE represented by finite strings?
Those are not the same project.
Peter,
I think this sentence finally identifies the fundamental difference
between your system and computability theory:
If we have no way to determine whether or not
X is true then X is necessarily outside of the
body of knowledge, thus outside of the domain
of my system.
That is perfectly coherent as a restriction on the domain of your system.
But then I don't see how you can conclude that you have eliminated undecidability.
You have excluded it.
Suppose I define
D = { propositions whose truth can be determined
by the permitted methods of my system }.
Then naturally:
for every X in D,
the truth of X can be determined by my system.
But this does not establish:
for every X,
the truth of X can be determined.
It establishes the first statement by restricting D.
In particular, consider HALT:
HALT(P,I) =
TRUE if program P halts on input I
FALSE otherwise.
The standard Halting Theorem says that there is no Turing machine H such that, for every P and I,
H(P,I) = HALT(P,I).
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
Does this program Halt?
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
Please ONLY PROVIDE CORRECT ANSWERS!
Now suppose some instances of HALT cannot be determined by your
permitted semantic methods.
An [incorrect question] is defined as any question such that
a correct answer does not exist from the set of all possible
answers.
According to what you have just written, those instances are:
outside of the domain of my system.
Fine.
But then your system has not decided HALT.
It has declined to include those cases in its domain.
There is an enormous difference between:
"There are no undecidable propositions in my domain"
and:
"There are no undecidable propositions."
The first can be obtained simply by defining the domain to contain only propositions for which an accepted determination exists.
The second is the extraordinary mathematical claim that would contradict standard undecidability results.
Your statement appears explicitly to give us the first, not the second.
This also clarifies something about our hardware discussion.
You now say:
Circuitry / lookup tables are type (1).
and type (1) is:
Stipulated relation foundational axioms.
That resolves our previous disagreement about ROM versus gates inside
your system: you are now treating both as stipulated relations.
But consider again the accidental ROM.
Suppose a ROM happens, completely accidentally, to contain the complete 8-bit addition mapping.
At time T1 nobody knows this.
We then exhaustively examine all 65536 entries and discover:
ROM[x,y] = (x+y) mod 256
for every x,y.
At time T2 we know that it implements addition.
Nothing whatsoever has changed inside the ROM between T1 and T2.
So did the ROM become an "axiom" at T2?
If so, "axiom" is not describing a computational property of the ROM.
It is describing our epistemic relationship to the ROM.
That seems consistent with your statement:
My system's domain is general knowledge
and also with the Prawitz passage concerning what it means to KNOW that
a sentence is true.
But that would make your project fundamentally a theory of knowledge/ justification, rather than a replacement foundation for computability.
And I think this distinction is now crucial.
Proof-theoretic semantics may tell us something about:
what justifies asserting X?
Computability theory asks:
what function does this machine compute?
Those are different questions.
There is also a smaller point about the carry-lookahead example.
You wrote:
Even a look-ahead carry generator implements conventional
elementary school 1st grade arithmetic.
Certainly it implements arithmetic.
But "implements arithmetic" is precisely the distinction I have been
making.
A carry-lookahead adder need not reproduce the elementary-school
sequential procedure. It uses generate/propagate logic specifically to reorganize carry dependencies so that they can be evaluated much more in parallel.
Different algorithms and radically different circuits can implement the
same mathematical function.
That is why I distinguish:
mathematical function/specification
implementation/computation
proof of correctness
But I think the domain issue is now much more fundamental than our
hardware examples.
So let me ask one very precise question.
Consider a particular HALT instance X for which your permitted methods provide no determination.
You have just said that such an X is outside the domain of your system.--
Does your system nevertheless return TRUE or FALSE for X?
If YES, please specify how it obtains the correct answer.
If NO, then X remains undecided.
Calling X "outside the domain" has not eliminated its undecidability.
It has only eliminated X from the set of questions your system
undertakes to decide.
Peter,
I think your latest reply reveals a very important change in the subject
of the discussion.
You wrote:
Sheer accident provides zero basis for knowledge.
My system's domain is general knowledge expressed
as relations between finite strings.
But I did not ask whether the accidental ROM provides a basis for
KNOWLEDGE.
I asked whether it COMPUTES the function.
Those are different questions.
Suppose the ROM happens to satisfy
ROM[x,y] = (x+y) mod 256
for every possible input.
Then there are at least three separate questions:
1. Does the device implement the addition mapping?
2. Do we know that it implements the addition mapping?
3. Can we prove that it implements the addition mapping?
The answer to (1) can be yes while the answers to (2) and (3) are no.
Indeed, that was precisely the purpose of the accidental-ROM example.
You replied that accident provides no basis for knowledge.
Agreed.
But that answers (2), not (1).
This also explains why I don't think the Prawitz reference establishes
what you need.
Proof-theoretic semantics is indeed concerned with explaining meaning in terms of proof, and Prawitz discusses the connection between knowing
that a mathematical sentence is true and having a proof of it.
But that is an epistemological/semantic claim about mathematical
assertion and proof.
It does not establish:
computation = justified knowledge
or:
every computational transition = semantic inference.
In fact, your latest formulation seems increasingly to describe a theory
of justified inference rather than a theory of computation.
There is another interesting development in your answer.
Previously, you said that lookup does not itself perform the computation because the computation was "off-loaded."
Now you say:
All of your table lookups are stipulated.
So my system remains correct and coherent.
and:
ROM is stipulated relations.
I am happy to accept that for the sake of argument.
But then any finite function can be represented as stipulated relations.
For a finite domain
A = {a1,...,an}
and any function f, I can stipulate
a1 -> f(a1)
a2 -> f(a2)
...
an -> f(an)
and implement exactly those stipulated relations in a ROM.
So the distinction between gate computation and ROM lookup has
disappeared from your criterion.
This also connects directly to actual computer hardware.
The same finite Boolean function can be implemented as:
gates
PLA
FPGA LUTs
ROM
and representations can be mechanically transformed between these forms.
If ROM relations qualify because they are "stipulated", then there is no longer any reason to say that computation was performed elsewhere and
merely stored in the ROM. The ROM itself implements the stipulated mapping.
More importantly, however, your present definition appears to be:
acceptable transformation =
semantically entailed transformation
OR
stipulated transformation.
That may define a formal system of justified transformations.
But why should that be identified with COMPUTATION?
Your Prawitz quotation may provide motivation for identifying
mathematical knowledge with proof under a proof-theoretic conception of meaning.
It does not provide the missing implication:
computation
=>
knowledge
=>
proof
=>
semantic entailment or stipulation.
And your final statement makes the problem especially clear:
It seems to me that the only category of proof that
I will be able to provide is self-evidence:
proven true on the basis of meaning.
I think this is exactly where we need to be extremely careful.
If your crucial foundational claim is:
Computation requires correct rather than
arbitrary finite string transformations
we need to distinguish two readings of "correct".
Reading A:
The machine actually produces the value specified
by the function.
Then the accidental ROM is correct, regardless of whether anybody knows
or can prove that it is correct.
Reading B:
The transformation is justified as correct by
semantic entailment or stipulation.
Then you have changed "correct computation" into "justified computation".
That is an epistemic notion.
And the Halting Theorem is not a theorem about what we can justify as knowledge. It is a theorem about what Turing machines can compute.
This distinction becomes especially important when you say:
Undecidability ceases to exist within this new foundation.
What is the correct return value that a halt decider
can provide for a program that does the opposite of
whatever value it returns?
Peter,
What is the correct return value that a halt decider
can provide for a program that does the opposite of
whatever value it returns?
Neither value.
And that is exactly the proof of the Halting Theorem.
An [incorrect question] is defined as any question such that a correct answer does not exist from the set of all possible answers.
Assume H is a correct total halt decider, and construct D so that:
if H(D) says HALTS:
D loops forever
if H(D) says DOES NOT HALT:
D halts
Now ask H(D).
If H(D) says HALTS, it is wrong.--
If H(D) says DOES NOT HALT, it is wrong.
Therefore there is no value H can return while remaining a correct halt decider.
But notice what follows logically.
It is NOT:
therefore D is an "incorrect question".
It is:
therefore the assumed correct total H does not exist.
That is the reductio.
We assumed:
H exists and correctly decides every program.
From that assumption we constructed D and derived:
H(D) cannot be correct.
Therefore the assumption is false.
In symbols:
Assume H exists.
Construct D using H.
H(D) = HALTS
=> D does not halt
=> H is wrong.
H(D) = DOES_NOT_HALT
=> D halts
=> H is wrong.
Therefore H cannot satisfy its assumed specification.
That is precisely the Halting Theorem.
Your question therefore does not expose a misconception in the proof.
It reproduces the contradiction used by the proof.
The only way to obtain a different conclusion is to explain why the contradiction should be attributed to the QUESTION rather than to the assumption that H exists.
And that requires an independent argument.
You cannot simply define:
a question for which no correct answer can be
returned by H is an "incorrect question"
because the entire purpose of the diagonal construction is to prove that
no such universally correct H exists.
Doing that would transform:
Assume H exists.
Derive contradiction.
Therefore H does not exist.
into:
Assume H exists.
Derive contradiction.
Therefore exclude the case producing the contradiction
from H's domain.
But that simply protects the original assumption by restricting its domain.
And then H is no longer a halt decider for all programs.
So to answer your simplified question as directly as possible:
What correct value can H return for D?
NONE.
And the standard conclusion is:
therefore a total correct H cannot exist.
If your conclusion is instead:
therefore D is outside H's domain,
then you have conceded the standard result:
H cannot decide halting for every program.
You have simply given the undecidable case a different name.
Peter,
I followed the x86utm link and read the README, and I think this finally gives us a very precise technical point to examine.
Your README says:
The key mistake of the halting problem proofs is that they
require a halt decider to report on the behavior of something
other than the behavior specified by its finite string input.
and Axiom 2 says:
The only correct finite string transformation rules that HHH
is allowed to apply to its finite string input DD is specified
by the operational semantics of the C programming language.
This requires DD to be simulated by HHH according to these rules.
I think the second statement is exactly where your argument departs from
the Halting Theorem.
A hypothetical halt decider is NOT required to determine termination by simulating its input.
Peter,
I think we have now achieved an important clarification, and I want to preserve it rather than continue arguing past it.
I wrote:
Then you have changed "correct computation"
into "justified computation".
That is an epistemic notion.
and you answered:
Yes. That is a correct clarification.
Good.
You have also now accepted that the ROM itself implements its stipulated mapping. So I think our hardware disagreement is essentially resolved.
The remaining issue is much narrower.
You write:
Deciders must apply finite string transformations that are
semantically relevant to the decision criteria.
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.
Axiom 1
--- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of
finite string transformation rules to finite string
inputs to derive any and all outputs.
Axiom 2
Computation requires correct rather than
arbitrary finite string transformations.
I think your three recent replies now identify the exact point on which
we disagree.
You say:
A halt decider is required to derive its result through
the application of finite string transformations to its
finite string input. The halting theorem totally ignores
this.
and:
A halt decider is also implicitly required to limit these
finite string transformations to those relevant to determining
the halting property specified by this finite string input.
The halting theorem totally ignores this.
and:
The halting theorem is framed as the impossibility of
a halt decider returning a correct value to its caller
that is not even its input.
I don't think the Halting Theorem ignores any of these issues.
I think you are conflating three different things:
1. the finite representation of a program P,
2. the computation denoted by that representation,
3. the context in which that computation is executed.
These are related, but they are not identical.
Consider an ordinary static analyzer A.
I can give A the finite source code:
int f() {
return 17;
}
The INPUT to A is a finite string representing f.
What A is asked to determine is a property of the computation denoted by that finite string.
There is no contradiction here between:
static finite string input
and:
executing process.
The finite string REPRESENTS the program whose possible execution we are reasoning about.
That distinction is fundamental to essentially all program analysis.
Likewise, there is no "mutual exclusivity" between a program being the caller of a function during one execution and a representation of that
same program being the input data of that function.
Assume H exists.
Then construct D:
D():
if H(<D>) == HALTS:
loop forever
else:
halt
Now ask H(<D>).
If H says HALTS, D does not halt.
If H says DOES_NOT_HALT, D halts.
You call this an "incorrect question".
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
Does this program Halt?
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
Please ONLY PROVIDE CORRECT ANSWERS!
An [incorrect question] is defined as any question such that
a correct answer does not exist from the set of all possible
answers.
Peter,
I think your latest example makes the disagreement extremely precise:
int main()
{
DD(); // is neither the input to HHH nor a finite static string
}
I completely agree with the comment.
DD() executing in main is NOT the input to HHH.
But the Halting Theorem does not require it to be.
When both of your own answers are wrong this proves
that I am correct.
Peter,
When both of your own answers are wrong this proves
that I am correct.
No. It proves exactly the Halting Theorem.
Peter,
When both of your own answers are wrong this proves
that I am correct.
No. It proves exactly the Halting Theorem.
You are overlooking what your program depends on.
Your 2004 example says:
if YOU say HALTS:
loop
else:
halt
So there is no answer that can be both:
1. supplied to the program, and
2. a correct prediction of the resulting behavior.
Agreed.
But that does not prove that halting is an "incorrect question".
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
Does this program Halt?
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
Please ONLY PROVIDE CORRECT ANSWERS!
I asked you for your answer and YOU failed.
Peter,
I asked you for your answer and YOU failed.
No. You failed to distinguish a prediction from an input that changes
what is being predicted.
Your 2004 question says explicitly:
Your YES or NO answer is translated to Boolean
as the function's input parameter.
So:
answer YES -> you run LoopIfYouSayItHalts(TRUE)
and:
answer NO -> you run LoopIfYouSayItHalts(FALSE).
Those are two different inputs and therefore two different computations.
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
Does this program Halt?
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
Please ONLY PROVIDE CORRECT ANSWERS!
Peter,
I asked you for your answer and YOU failed.
No. You failed to distinguish a prediction from an input that changes
what is being predicted.
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
Does this program Halt?
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
Please ONLY PROVIDE CORRECT ANSWERS!
Peter,
No. This is now simply a logical error on your part.
You define the rules as follows:
YES is used as TRUE input.
NO is used as FALSE input.
Peter,
No. This is now simply a logical error on your part.
You define the rules as follows:
YES is used as TRUE input.
NO is used as FALSE input.
Your program then computes:
TRUE -> loops
FALSE -> halts
Therefore:
answer YES -> YES is false
answer NO -> NO is false
In Boolean notation, you are demanding a value b such that:
b = NOT b.
There is no such Boolean value.
Your response is now:
(a) YES is wrong
(b) NO is wrong
(c) explaining that neither can be correct is also wrong,
because only YES or NO is permitted.
That does not prove that the person answering has failed.
It proves that YOU specified a multiple-choice problem having no correct choice.
Saying:
"You must choose A or B"
does not logically imply:
"Either A or B must be correct."
For example:
Which integer satisfies x = x + 1?
(a) 0
(b) 1
If I answer:
neither
you cannot refute me by saying:
TYPE MISMATCH! Only 0 or 1 was allowed!
Neither allowed answer satisfies the specification.
On 10/19/2026 9:05 AM, Python wrote:What purpose would a DD that does not call HHH serve?
Peter,
I think your latest example makes the disagreement extremely precise:
int main()
{
DD(); // is neither the input to HHH nor a finite static string >> }
I completely agree with the comment.
DD() executing in main is NOT the input to HHH.
But the Halting Theorem does not require it to be.
DD cannot possibly do the opposite of whatever HHH
returns to it when DD is not the caller of HHH.
And both are the wrong answer
Peter,
I have now read both references.
They are relevant, but citing them does not answer my argument.
Stoddart explicitly says that the dissenting view AGREES that the
halting function as specified cannot be implemented, but attributes this
to an inconsistent specification.
That is precisely the issue we are discussing.
So we agree on the mathematics:
YES is wrong.
NO is wrong.
Equivalently:
b = NOT b
has no Boolean solution.
The dispute is ONLY about what follows from that contradiction.
The standard diagonal argument says:
the assumed total universally correct H cannot exist.
You, Hehner, and Stoddart propose instead to blame the specification/ question.
Fine. That is a position.
But citing two people who advocate that interpretation is not a proof of that interpretation.
In fact, Hehner himself explicitly acknowledges that his position contradicts the universally accepted one and asks readers to identify
where his argument goes wrong.
So we are back to the exact question you keep avoiding:
WHY does
no Boolean b satisfies b = NOT b
entail
the diagonal question must be rejected
rather than
the assumed universal H cannot exist?
Stoddart and Hehner do not make that logical burden disappear.
They are references for your position, not proofs that my objection is false.
And notice something important:
Nobody here is disputing the contradiction anymore.
You, I, Hehner and Stoddart all reach it.
The entire dispute is about which assumption the contradiction refutes.
So authority cannot settle this.
The inference can.--
Please give it.
Peter,
And both are the wrong answer
Yes.
That is exactly what I just said.
You are not rebutting my argument. You are repeating its central premise.
YES is wrong.
NO is wrong.
Agreed.
Now comes the part you keep avoiding:
WHY are both wrong?
Because your specification requires a Boolean b satisfying:
b = NOT b.
No such Boolean exists.
You conclude:
therefore the question is incorrect.
The diagonal argument concludes:
therefore the assumed universally correct
Boolean decider does not exist.
Repeating "BOTH ANSWERS ARE WRONG" in increasingly emphatic language
does not decide between those conclusions.
That is the very fact whose logical consequence is under dispute.--
So stop telling me that both answers are wrong.
I already agree.
Show the missing inference:
no b satisfies b = NOT b
THEREFORE
the question must be excluded
rather than:
the assumed universally correct decider cannot exist.
That is the step you need to prove.
Until you do, you are not refuting the Halting Theorem.
You are repeatedly announcing its contradiction and refusing its
conclusion.
On 19/10/2026 17:34, olcott wrote:
On 10/19/2026 9:05 AM, Python wrote:What purpose would a DD that does not call HHH serve?
Peter,
I think your latest example makes the disagreement extremely precise:
int main()
{
DD(); // is neither the input to HHH nor a finite static string
}
I completely agree with the comment.
DD() executing in main is NOT the input to HHH.
But the Halting Theorem does not require it to be.
DD cannot possibly do the opposite of whatever HHH
returns to it when DD is not the caller of HHH.
An input to a halt decider that calls this
same halt decider and does the opposite
of whatever it reports cannot possibly exist.
Every question such that all the answers are the wrong
answer is an incorrect question
Peter,
An input to a halt decider that calls this
same halt decider and does the opposite
of whatever it reports cannot possibly exist.
That is simply false.
The INPUT can certainly exist.
Peter,
An input to a halt decider that calls this
same halt decider and does the opposite
of whatever it reports cannot possibly exist.
That is simply false.
The INPUT can certainly exist.
Here it is, schematically:
D:
if H(<D>) == HALTS:
loop forever
else:
halt
That is a finite program.
It has a finite encoding <D>.
So <D> exists.
What cannot exist is a TOTAL CORRECT H satisfying:
H(<P>) = the correct halt status of P
for every finite program P, including D.
You have reversed the conclusion of the proof.
The diagonal argument does NOT prove:
D cannot exist.
It proves:
D exists
AND
if universal correct H exists,
H must fail on D
therefore:
universal correct H cannot exist.
Now consider your other statement:
Every question such that all the answers are the wrong
answer is an incorrect question
Fine. I can even grant your terminology.
Call it an "incorrect question".
It changes nothing.
The important question is WHY your "incorrect question" arose.
It arose from these assumptions:
1. H exists.
2. H is total.
3. H correctly decides every finite program.
4. D is a finite program constructed using H.
Those assumptions imply that neither possible H(<D>) value can be correct.
Therefore they are jointly inconsistent.
You keep saying:
both answers are wrong,
therefore incorrect question.
I keep agreeing that both answers are wrong.
What you still have not supplied is the inference that lets you preserve assumptions 1-3 and reject 4.
In fact, 4 is constructive: D is right there.
Calling diagonalization a "shortcut" does not change this.
And saying that people reject your argument because of "emotional conviction" or "herd of sheep mentality" is irrelevant.
There is no sociology in:
D is finite.
<D> exists.
H(<D>) = HALTS -> H is wrong.
H(<D>) = NONHALT -> H is wrong.
Therefore no total universally correct H exists.--
So please address the mathematical statement you just made:
"An input ... cannot possibly exist."
Why not?
Which finite part of D above is impossible to encode?
If you cannot identify one, then the diagonal input exists.
It is the universal correct decider that does not.
Peter,
Now I see exactly where your argument goes wrong.
You write:
Input to H / caller of H are inherently mutually exclusive.
Of course they are.
Nobody claims otherwise.
The caller of H and the input to H are TWO DIFFERENT OBJECTS.
Here is the construction:
int DD(void)
{
if (HHH(code_of_DD))
for (;;) {}
return 0;
}
When DD executes this line:
HHH(code_of_DD)
then:
It is not the static finite string input to HHH.
Peter,
It is not the static finite string input to HHH.
Then what IS the static finite string input to HHH?
Let's eliminate the ambiguous word "input" and name the three objects separately:
1. caller:
the executing invocation of DD
2. argument data:
the finite string code_of_DD
3. subject program:
DD, whose halting behavior HHH is asked to determine
The call is:
HHH(code_of_DD)
So if HHH is a function operating on finite strings, then by ordinary function-call semantics:
code_of_DD
is its argument data.
DD remains the caller.
They are not identical.
Your statement:
All of the proofs assume that an input to a halt decider
can do the opposite of whatever this decider reports.
is therefore not accurate.
The finite string does not "do" anything.
The construction is:
DD executes.
DD calls HHH(code_of_DD).
HHH examines the finite string code_of_DD.
HHH returns a Boolean to DD.
DD uses that Boolean to choose its subsequent behavior.
So:
finite string code_of_DD does not call HHH.--
finite string code_of_DD does not loop.
finite string code_of_DD does not halt.
executing DD does those things.
The finite string specifies DD.
There is no violation of your mutual-exclusivity requirement:
caller != argument data.
In fact:
caller = executing DD
argument data = code_of_DD
throughout the entire call.
Now you say:
code_of_DD is not the static finite string input to HHH.
Fine.
Please complete this sentence:
In the call HHH(code_of_DD),
the static finite string input to HHH is __________.
Because if your HHH applies finite-string transformations to a finite- string input, there must be some finite string to which those transformations are applied.
If that string completely specifies DD, call it S instead:
HHH(S)
Nothing changes:
DD is the caller.
S is the finite-string argument.
S completely specifies DD.
HHH returns its result to DD, and DD does the opposite.
At no point does S become the caller.
So your claimed entailment:
subject of analysis does opposite of HHH's result
entails
finite-string argument = caller
is false.
It does not entail that at all.
It only requires the caller DD to be the computation specified by the
finite data supplied to HHH.
Those are two different objects.
So please don't tell me again that I am "not paying close enough
attention."
Just answer the concrete question:
In HHH(code_of_DD), what exactly is HHH's
static finite-string input?
If your answer is "code_of_DD", your mutual-exclusivity objection disappears.
If your answer is "not code_of_DD", tell me what finite string HHH
actually receives.
The behavior of the directly executed DD has always been
outside of the domain of HHH.
HHH(DD)==0 is correct.
Peter,
Excellent. Now we finally have a completely concrete object, and your machine-code listing actually resolves the ambiguity.
You say that the static finite-string input is literally these 35 bytes:
55
8bec
51
6862210000
e862f4ffff
...
c3
Fine. I accept that definition.
Now look at your own instructions:
[00002166] 6862210000 push 00002162 // push DD
[0000216b] e862f4ffff call 000015d2 // call HHH
So an executing DD calls HHH and supplies 0x2162, the location of the machine-code bytes of DD.
Those bytes can be READ BY HHH as data.
The same bytes can be EXECUTED BY THE CPU as instructions.
There is no contradiction whatsoever.
The bytes do not execute themselves while HHH reads them.
An execution of DD executes them.
Therefore we have exactly the distinction I described:
caller:
executing DD
finite object examined by HHH:
the machine-code bytes beginning at 0x2162
computation whose behavior those bytes specify:
DD
Your own machine-code example demonstrates all three.
But now you say something much more important:
The behavior of the directly executed DD has always been
outside of the domain of HHH.
THAT is the issue.
If directly executing the program specified by HHH's finite-string input
is outside the domain of HHH, then HHH is not a universal halt decider.
You have restricted its domain.
The standard problem asks for H such that, for every program P and
relevant input I,
H(<P>, I)
correctly determines whether executing P on I halts.
HHH(DD) // DD calls HHH(DD)
HHH1(DD) // DD does not call HHH1 at all
This empirically proves that DD in those two different
contexts have two different execution traces
Computation already said that it must be a finite string
and the directly executable DD has never been a finite string.
This assumes that the DD in HHH(DD) and HHH1(DD) have
identical behavior.
Peter,
Now we have isolated two different issues.
First:
HHH(DD) // DD calls HHH(DD)
HHH1(DD) // DD does not call HHH1 at all
This empirically proves that DD in those two different
contexts have two different execution traces
Of course they can have different execution traces.
Nobody disputes that.
DD explicitly calls HHH.
Therefore changing the environment from HHH to HHH1 can change the computation.
That does NOT refute the Halting Theorem.--
In fact, consider the two concrete systems:
System A:
DD calls HHH
System B:
DD calls HHH
but we ask HHH1 to analyze DD
In System B, HHH1 is an observer of the computation involving HHH.
It is not the function DD calls.
So there is no diagonal relation between DD and HHH1.
Consequently there is nothing surprising about:
HHH(DD) = 0
HHH1(DD) = 1
if the two calls are asking about different completely specified computations.
The diagonal construction concerns the decider that DD actually calls.
Now to the more fundamental error.
You write:
Computation already said that it must be a finite string
and the directly executable DD has never been a finite string.
Correct.
And completely irrelevant.
Nobody claims that an executing DD is a finite string.
The DOMAIN of H can consist entirely of finite strings.
For example:
H : finite strings -> {0,1}
The SEMANTICS of a finite string tells us which computation it specifies.
H receives the string.
H answers a question about the computation specified by that string.
These are different levels.
For example, suppose I define:
S("4") = 2
where S takes a decimal string and returns the positive square root of
the number denoted by that string.
The domain of S consists of strings.
The number 4 is not a string.
That does not prevent the string "4" from specifying the number whose
square root S computes.
So your dead-chicken analogy misses the distinction.
The standard halting formulation does NOT put an executing process into
H's input domain.
It puts a finite description of a computation into H's input domain and
asks H about the execution specified by that finite description.
You object to the word "description", so use your own terminology:
a self-contained finite string completely specifying
a sequence of computational steps.
Fine.
Then HHH receives exactly such a finite string.
The question is whether the completely specified execution reaches its
final halt state.
Nothing requires the execution itself to be a finite string.
This is therefore not a domain error.
It is ordinary semantics:
finite string S
|
| specifies
v
computation C
HHH's DOMAIN contains S.
HHH's ANSWER concerns C.
You are conflating those two statements.
And your own x86 emulator necessarily makes exactly this distinction.
It receives machine-code bytes as data and interprets those bytes as instructions defining an execution.
The bytes are finite.
The execution may be infinite.
If your claim were correct, an emulator could never reason about an
infinite execution because the infinite execution is not itself a finite string.
But of course it can begin executing a finite program whose execution
never terminates.
Finally, you write:
This assumes that the DD in HHH(DD) and HHH1(DD) have
identical behavior.
No.
The Halting Theorem assumes no such thing.
For EACH completely specified computational system, ask whether a total correct halt decider exists for all finite program strings in that system.
Then diagonalize against THAT decider.
If DD calls HHH, diagonalize against HHH.
If another DD1 calls HHH1, diagonalize against HHH1.
There is no theorem saying that DD calling HHH and DD calling HHH1 must
have identical traces.
You have introduced that requirement yourself.
So your empirical result does not contradict the theorem at all.
It merely shows the obvious:
changing something that a program calls
can change the program's execution.
The actual question remains the one your own x86 listing makes unavoidable.
For the system in which DD calls HHH:
HHH returns 0
-> DD reaches RET
HHH returns 1
-> DD enters the infinite JMP
What does HHH correctly return for THAT completely specified computation?
0 cannot be correct, because after 0 the computation halts.
1 cannot be correct, because after 1 the computation does not halt.
You call that an "incorrect question."
Fine.
The standard theorem calls it the contradiction showing that the assumed total correct HHH cannot exist.
Your HHH1 experiment does not alter a single step of that argument.
Thus making HHH(DD)==0 correct as the halting property
specified by the finite string input to HHH
Peter,
Good. This sentence finally gives us a precise claim to test:
Thus making HHH(DD)==0 correct as the halting property
specified by the finite string input to HHH
Then please define exactly what you mean by:
"the halting property specified by the finite string"
because we now have the actual finite string.
It contains:--
call HHH
...
cmp result,0
jz exit
jmp forever
...
ret
Now suppose HHH returns 0.
The x86 execution specified by those bytes continues:
HHH returns EAX=0
cmp ...,0
jz is taken
...
ret
Therefore that execution HALTS.
This is not diagonalization.
It is not a guess.
It is not an abstraction.
It is simply the state-transition sequence of YOUR x86 code after HHH returns 0.
So explain exactly how:
HHH(DD) == 0
can correctly mean:
the execution specified by these bytes does not halt
when those same bytes specify that, after HHH returns 0, execution
reaches RET.
Your HHH1 comparison cannot answer this.
HHH1(DD) asks another decider about a computation in which DD calls HHH.
Fine.
But we are asking about:
HHH(DD)
in the system where DD actually calls HHH.
You claim 0 is correct there.
So stay with that single case.
There are only two possibilities.
Either the finite string given to HHH specifies the complete execution
of those x86 instructions.
Then:
HHH returns 0 -> execution reaches RET
and 0 cannot correctly mean NONHALT.
Or the "halting property" that HHH reports is NOT the halting behavior
of the complete execution specified by those x86 instructions.
Then tell me exactly what property HHH is deciding instead.
But you cannot have both:
1. HHH(DD)==0 correctly means that executing DD does not halt.
and:
2. after HHH(DD)==0, executing DD reaches RET.
Those statements contradict each other.
And notice that I am not invoking the Halting Theorem here.
I am asking you to follow your own x86 code from the return of HHH to RET.
So one very concrete question:
HHH returns 0 at 0x2170.
Does that execution of DD subsequently
reach RET at 0x2184?
YES or NO?
Please answer that before invoking HHH1, diagonalization, domains, or
the Halting Theorem.
Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own line 03 (whether or not HHH ever aborts this simulation)
whether or not HHH ever aborts this simulation
Peter,
Now the exact error is visible.
You write:
Simulation invariant
DD correctly simulated by HHH cannot possibly reach past its own line 03
(whether or not HHH ever aborts this simulation)
The parenthetical statement is false.
It makes ALL the difference whether HHH aborts the simulation and
returns a value.
Let's follow your exact C code.
You have:
03 int Halt_Status = HHH(DD);
04 if (Halt_Status)
05 HERE: goto HERE;
06 return Halt_Status;
As long as HHH(DD) does not return, DD remains blocked at line 03.
Agreed.
But now suppose HHH aborts its recursive simulation and returns 0.
Then line 03
COMPLETES:--
Halt_Status = 0;
Execution continues to line 04:
if (0)
which is false.
Line 05 is skipped.
Execution reaches line 06:
return 0;
DD halts.
So your claimed invariant:
DD cannot possibly reach past line 03
is true only under the condition:
HHH(DD) never returns.
But you then use that observation to make HHH(DD) RETURN 0.
The moment HHH returns 0, the condition supporting your conclusion
becomes false and DD proceeds to its final state.
That is the circularity.
In compact form:
If HHH never returns,
DD never gets past line 03.
Correct.
But that does NOT imply:
Therefore HHH may return 0
while DD still never gets past line 03.
Once HHH returns 0:
line 03 completes
-> line 04 is false
-> line 06 executes
-> DD halts.
Your phrase:
whether or not HHH ever aborts this simulation
is therefore exactly where the error occurs.
There are two cases:
HHH does not abort/return:
DD remains at line 03.
HHH aborts and returns 0:
DD passes line 03 and halts at line 06.
You cannot take the behavior from the first case and use it as the justification for the answer returned in the second case.
And notice something else important.
Your recursive simulation:
HHH simulates DD
-> DD calls HHH
-> HHH simulates DD
-> DD calls HHH
-> ...
does establish that straightforward simulation alone will recurse forever.
But that proves that THIS SIMULATION does not terminate.
It does not prove that DD would not terminate if HHH returned 0.
Indeed, your own C code proves the opposite.
So now we can identify the precise invalid inference:
"HHH's recursive simulation does not reach DD's final state"
does NOT entail:
"DD will not reach its final state after HHH returns NONHALT."
Those are different statements.
The second is actually false for your program.
No appeal to the Halting Theorem is needed to see this.
Just execute your lines 03 through 06 after HHH returns 0.
Therefore I will repeat the concrete question, now at the C level you requested:
HHH aborts its simulation and returns 0
to DD at line 03.
Does DD then reach line 06?
YES or NO?
becomes instantly totally dead along with every
aspect of the entire nested simulated instance.
Peter,
becomes instantly totally dead along with every
aspect of the entire nested simulated instance.
Good. That clarifies what you mean by "abort".
You mean that the OUTER HHH abandons the entire nested simulation and returns its answer to its own caller, rather than allowing the simulated
HHH at DD's line 03 to return normally to that simulated DD.
Fine.
Then my previous wording conflated two different operations, and I will correct it.
But this makes the problem with your argument even clearer.
You have established:
HHH begins simulating DD.
simulated DD reaches line 03 and invokes simulated HHH(DD).
this recursively produces further simulations.
HHH eventually ABORTS the whole nested simulation.
therefore none of the abandoned simulated DD instances
reaches line 06.
Agreed.
But from that you conclude:
therefore DD does not halt.
That does not follow.--
You have proved only:
the simulation that HHH chose to abort
did not reach DD's final state before HHH aborted it.
Of course it didn't.
You killed it.
That is a property of HHH's simulation procedure, not yet a proof of the halting property of DD.
The distinction is crucial:
ABORT THE SIMULATION
is not the same operation as:
simulated HHH returns 0 to simulated DD.
In the first case, you destroy the simulated DD.
In the second case, DD continues:
03 Halt_Status = 0;
04 if (Halt_Status) // false
05 goto HERE;
06 return Halt_Status; // HALT
So now the issue can be stated even more precisely.
Your justification for returning 0 is:
"During my recursive simulation, DD never reaches line 06."
But it never reaches line 06 because the simulation either:
(a) recursively continues forever,
or:
(b) YOU abort it before allowing the pending HHH call
to return to DD.
Neither establishes that DD would fail to reach line 06 if HHH actually returned 0 to it.
In fact, the C semantics establish the opposite:
if HHH returns 0 to DD,
DD reaches line 06 and halts.
So please distinguish these two events:
A. HHH aborts/destroys its internal simulation of DD.
B. HHH returns 0 to the DD that called it.
A does not cause the abandoned simulated DD to continue.
Agreed.
But the halt decision is supposed to concern what DD does under the semantics of its calls, not whether your simulator chose to destroy an internal simulation.
And B unquestionably causes DD to continue to line 06.
Therefore the unanswered question remains, now without any ambiguity
about "abort":
Suppose an actual execution of DD reaches line 03
and HHH(DD) returns 0 normally to that DD.
Does that DD reach line 06?
YES or NO?
If YES, then 0 is not a correct prediction that this DD does not halt.
If NO, identify the C rule preventing execution from proceeding from
line 03 to line 04 after HHH returns 0.
Your statement that an ABANDONED SIMULATION is "totally dead" does not answer this question.
It merely confirms that you are treating:
"my simulator stopped following this execution"
as if it meant:
"this execution cannot halt."
Those are not equivalent.
HHH correctly determines that its own input DD
cannot possibly reach its own line 06
You still have not answered the question.
Your claim is:
HHH(DD) returns 0
and your DD is:
Halt_Status = HHH(DD);
if (Halt_Status)
goto HERE;
return Halt_Status;
So assume your claimed result:
HHH(DD) returns 0.
Then ordinary C semantics give:
Halt_Status = 0;
if (0) // false
return 0; // line 06 reached
Therefore DD halts.
Your statement:
HHH correctly determines that its own input DD
cannot possibly reach its own line 06
is exactly what you need to prove.
You cannot prove it by observing an infinite recursive simulation, then aborting that simulation, returning 0, and ignoring what the caller does with that 0.
Everything else is irrelevant.--
One question:
If HHH(DD) returns 0 normally to DD at line 03,
does DD reach line 06?
YES or NO?
If YES, HHH's 0 is wrong.
If NO, identify the C semantic rule that prevents line 04 from executing.
There is no third possibility.
On 10/19/2026 5:32 AM, Python wrote:
I think you are conflating three different things:
1. the finite representation of a program P,
The terminology is conventional and incorrect.
It never has had the indirect reference that
"representation of a program" has lead people
to believe.
(1) The term "description" is too vague. It never
has been any mere description it has always be a
100% completely specified sequence of steps.
(2) It never has has any indirect reference to any
program that exists somewhere else. It has always
been a completely self-contained exact sequence of steps.
You already agreed to that long ago.
Peter,
You are answering a different call.
You show:
main()
{
HHH(DD); // HHH returns 0 to main
}
I asked about:
DD()
{
Halt_Status = HHH(DD); // HHH returns 0 to DD
if (Halt_Status)
goto HERE;
return Halt_Status;
}
These are different callers.
Your:
Input_Halts = 0
shows only that the OUTER HHH returns 0 to main.
It does not answer my question about the INNER call.
So, once again, with no simulation and no theorem involved:
DD is executing.
DD reaches line 03.
HHH(DD) returns 0 TO DD.
What happens next?
By C semantics:
Halt_Status = 0;
if (0) // false
return 0; // line 06
Therefore DD halts.
You have now repeatedly answered a question about:
HHH -> main
instead of the question I actually asked:
HHH -> DD
And:
You already agreed to that long ago.
No. I agreed that DD cannot pass line 03 WHILE its call to HHH has not returned.
That is completely different from claiming DD cannot pass line 03 AFTER
HHH returns 0.
So please answer exactly this and nothing else:
If the HHH called at DD line 03
returns 0 to that DD,
does DD reach line 06?--
YES or NO?
On 19/10/2026 17:19, olcott wrote:
On 10/19/2026 5:32 AM, Python wrote:
I think you are conflating three different things:
1. the finite representation of a program P,
The terminology is conventional and incorrect.
It never has had the indirect reference that
"representation of a program" has lead people
to believe.
(1) The term "description" is too vague. It never
has been any mere description it has always be a
100% completely specified sequence of steps.
In Turing's orignal article specified how the description shall
be encoded.
(2) It never has has any indirect reference to any
program that exists somewhere else. It has always
been a completely self-contained exact sequence of steps.
A "program" (or more commonly "algorithm" or "Turing machine")
is a finite set of distinct rules that specify an action for
every configuration without any reference to anyting external.
That the description doesn't refer to anything external follows
from that. Consequently the encoding rules of the description
need not allow external references.
What you have falsely presented as counter-examples does not
satisfy these restrictions.
You already agreed that is impossible for the relevant DD.
Peter,
You already agreed that is impossible for the relevant DD.
No.
I agreed to this:
If HHH keeps recursively simulating DD,
the simulated call to HHH never returns.
I did NOT agree to this:
Therefore HHH has correctly proved that DD does not halt.
Those are different propositions.--
In fact, your code demonstrates why.
You say the inner HHH cannot return 0 because doing so would allow DD to continue.
Exactly.
If it returns 0:
DD reaches line 06 and halts.
If it does not return:
DD remains at line 03.
THAT IS THE DIAGONAL DEPENDENCY.
You cannot now say:
"HHH cannot return 0 to DD,
therefore HHH correctly returns 0 to main."
That is not a halt decision about DD.
It is a statement about what happens when your analyzer recursively
tries to analyze DD.
Your result establishes:
recursive simulation of DD by HHH does not terminate normally.
It does NOT establish:
DD does not halt.
Indeed, DD's behavior depends on the result of HHH:
HHH returns 0 -> DD halts
HHH returns 1 -> DD loops
HHH never returns -> DD waits forever
So there is no value HHH can return to DD that correctly predicts the resulting behavior.
That is precisely the contradiction.
You have not escaped diagonalization.
You have implemented it.
Peter,
No. You are still changing what I agreed to.
I agreed that:
IF every simulated HHH(DD) recursively simulates DD
without returning,
THEN the simulated DD cannot reach line 06.
That is:--
HHH does not return -> DD does not halt.
You are claiming that this proves:
DD does not halt.
It does not.
Your Axioms 1 and 2 do not bridge that logical gap.
Calling your simulation steps "the only semantically relevant finite
string transformations" does not make the missing premise disappear.
Your DD specifies:
HHH(DD) returns 0 -> DD halts
HHH(DD) returns 1 -> DD loops
HHH(DD) never returns -> DD waits forever
Therefore the behavior specified by DD is not simply:
"a non-halting sequence of configurations"
independently of HHH.
It depends on HHH.
Your recursive simulation selects the third branch:
HHH never returns.
Then you observe:
DD never reaches line 06.
Correct.
But you subsequently use that observation to justify producing:
HHH(DD) = 0.
And 0 selects the FIRST branch:
HHH returns 0 -> DD halts.
That is the error.
You cannot establish the behavior under:
HHH never returns
and then claim it remains the behavior under:
HHH returns 0.
Those are different executions of your own transition rules.
So please stop saying that I agreed "DD can't possibly halt."
I agreed to the conditional:
IF HHH never returns, DD cannot halt.
I emphatically do not agree to:
DD cannot halt.
And your own C code refutes the latter:
HHH returns 0 -> DD reaches line 06.
If your "semantically relevant transformations" exclude that transition, then they are not faithfully implementing the semantics of the C program
you supplied.
This has nothing to do with arbitrary versus relevant transformations.
It is elementary logic:
P -> Q
does not imply:
Q.
Your entire conclusion depends on dropping P.
DD simulated by HHH according to the operational semantics of
the C programming language cannot possibly reach its own line
06 and halt whether or not HHH ever aborts this simulation.
Peter,
This is getting seriously frustrating.
You are simply repeating the assertion I have just challenged instead of answering the challenge.
DD simulated by HHH according to the operational semantics of
the C programming language cannot possibly reach its own line
06 and halt whether or not HHH ever aborts this simulation.
STOP.
"HHH aborts its simulation" is NOT the question.
The question is what happens when the HHH CALL AT LINE 03 RETURNS 0 TO DD.
Your own C code is:--
03 Halt_Status = HHH(DD);
04 if (Halt_Status)
05 goto HERE;
06 return Halt_Status;
Now apply the operational semantics of C that you keep invoking.
If the call at line 03 returns 0:
Halt_Status = 0;
then control proceeds to line 04:
if (0)
which is false, so control proceeds to line 06:
return 0;
DD HALTS.
There is nothing left to interpret here.
You keep responding:
"But my OUTER HHH aborts the simulation."
I KNOW.
That is not an answer.
You are using the fact that your simulator destroys the simulated
execution before line 06 as "proof" that the program cannot reach line 06.
That is absurd.
If I terminate a debugger while it is running a program, I have not
proved that the program cannot terminate.
And after all these messages, you still refuse to answer the simplest question in the entire discussion:
IF THE HHH CALL AT DD LINE 03 RETURNS 0 TO DD,
DOES DD REACH LINE 06?
YES or NO?
Not:
"the outer simulation is aborted."
Not:
"the simulated instance is dead."
Not:
"only semantically relevant transformations count."
Not Post.
Not Prawitz.
Not x86.
Not HHH1.
YES or NO.
If YES, then your claim that DD "cannot possibly reach line 06" is false.
If NO, show the C operational-semantic transition that prevents
execution from going from line 03 to line 04 after the function call returns.
You cannot keep claiming to be following "the operational semantics of
C" while refusing to follow the most elementary operational transition
in the program.
After this many exchanges, repeating "cannot possibly reach line 06" is
no longer an argument.
It is precisely the proposition you have been asked to prove.
THIS CANNOT POSSIBLY HAPPEN
Peter,
GOOD. FINALLY.
THIS CANNOT POSSIBLY HAPPEN
Then you have finally admitted the problem.
HHH CANNOT RETURN ITS SUPPOSED HALTING DECISION TO THE DD WHOSE HALTING BEHAVIOR IT CLAIMS TO HAVE DECIDED.
That is not a refutation of the Halting Theorem.
THAT IS THE FUCKING PROBLEM.
You keep boasting that:
HHH(DD) == 0
is a correct halt decision.
But when I ask what happens if that 0 is actually returned to the
relevant DD, you now scream:
THIS CANNOT POSSIBLY HAPPEN.
Exactly.
Because if it happens:
HHH returns 0
-> DD receives 0
-> if (0) is false
-> DD reaches line 06
-> DD HALTS
making the 0 wrong.
And if HHH returns 1:
HHH returns 1
-> DD receives 1
-> DD loops
-> DD DOES NOT HALT
making the 1 wrong.
So your only escape is:
HHH must not return either answer to the relevant DD.
YES.
THAT IS THE DIAGONAL CONTRADICTION.
Returning 0 to MAIN after killing an internal simulation does not
magically turn that 0 into a correct answer returned to DD.
You have changed:
HHH returns 0 to DD
into:
outer HHH aborts its simulation and returns 0 to main.
Those are not the same computation.
And then you have the nerve to accuse ME of changing the subject.
No.
I have been asking the SAME question for message after message:
What happens if the HHH called by DD returns 0 to DD?
You have finally answered:
IT CANNOT POSSIBLY HAPPEN.
Fine.
Then HHH is not a total halt decider for that call.
End of story.
Your "relevant finite string transformations" do not rescue you. They
are merely the machinery by which you discovered that HHH cannot return
a correct Boolean answer to the diagonal caller.
That is exactly what the theorem says.
You have spent dozens of messages constructing the diagonal
contradiction in an x86 emulator, observing it experimentally, and then declaring that the contradiction refutes the theorem rather than your supposed decider.
It doesn't.
Your own answer now establishes:
0 cannot be returned correctly.
1 cannot be returned correctly.
refusing to return is not a total decision.
There are no cases left.
You have not refuted the Halting Theorem.
You have built a remarkably elaborate demonstration of it.
That you keep insisting that it must report on
something other than what its finite string
input specifies seems dishonest at this point.
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 Ĥ.
This new machine takes as input WM, copies it,
and then behaves exactly like H'. Then the action
of Ĥ is such that
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.
</Linz text>
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.
Axiom 1
--- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of
finite string transformation rules to finite string
inputs to derive any and all outputs.
Axiom 2
Computation requires correct rather than
arbitrary finite string transformations.
The brand new key insight that I had into the
foundations of computation is the notion of
{correct finite string transformations} as
opposed to and contrast with {arbitrary finite
string transformations}.
If we need to know the sum of 2 + 3 there seems
to be only a single sequence of finite string
transformation rules that derive this within
arithmetic operations on the integer type. This
is one concrete example of how computation is
limited to correct finite string transformations.
On 10/20/2026 2:23 AM, Mikko wrote:
On 19/10/2026 17:34, olcott wrote:
On 10/19/2026 9:05 AM, Python wrote:What purpose would a DD that does not call HHH serve?
Peter,
I think your latest example makes the disagreement extremely precise:
int main()
{
DD(); // is neither the input to HHH nor a finite static string
}
I completely agree with the comment.
DD() executing in main is NOT the input to HHH.
But the Halting Theorem does not require it to be.
DD cannot possibly do the opposite of whatever HHH
returns to it when DD is not the caller of HHH.
That DD() is incorrectly presumed to be the counter-example
input static finite string to the Halting Theorem.
(a) It is not an input it is the caller
(b) It is an executing process thus not a static finite string
On 10/21/2026 2:53 AM, Mikko wrote:
On 19/10/2026 17:19, olcott wrote:
On 10/19/2026 5:32 AM, Python wrote:
I think you are conflating three different things:
1. the finite representation of a program P,
The terminology is conventional and incorrect.
It never has had the indirect reference that
"representation of a program" has lead people
to believe.
(1) The term "description" is too vague. It never
has been any mere description it has always be a
100% completely specified sequence of steps.
In Turing's orignal article specified how the description shall
be encoded.
It misleading and in all my work henceforth called the
source code of a Turing Machine.
On 10/19/2026 10:35 AM, Python wrote:Maybe it is, maybe not. You don't know, and neither does anybody else.
Peter,
When both of your own answers are wrong this proves
that I am correct.
No. It proves exactly the Halting Theorem.
You are overlooking what your program depends on.
Your 2004 example says:
if YOU say HALTS:
loop
else:
halt
So there is no answer that can be both:
1. supplied to the program, and
2. a correct prediction of the resulting behavior.
Agreed.
But that does not prove that halting is an "incorrect question".
On 6/23/2004 9:34 PM, Peter Olcott wrote:
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
Does this program Halt?
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
Please ONLY PROVIDE CORRECT ANSWERS!
I asked you for your answer and YOU failed.
This is NOT a fundamental limit to human reasoning
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 Ĥ.
This new machine takes as input WM, copies it,
and then behaves exactly like H'. Then the action
of Ĥ is such that
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.
</Linz text>
Irrelevant. The topic of the discussion woas the meaning of "halting
problem" which is already defined before the headline of theorem 12.1.
On 16/10/2026 16:28, olcott wrote:
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.
Axiom 1
--- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of
finite string transformation rules to finite string
inputs to derive any and all outputs.
Axiom 2
Computation requires correct rather than
arbitrary finite string transformations.
The brand new key insight that I had into the
foundations of computation is the notion of
{correct finite string transformations} as
opposed to and contrast with {arbitrary finite
string transformations}.
If we need to know the sum of 2 + 3 there seems
to be only a single sequence of finite string
transformation rules that derive this within
arithmetic operations on the integer type. This
is one concrete example of how computation is
limited to correct finite string transformations.
You are trying to deceive with tanother switch of topic.
On 20/10/2026 17:29, olcott wrote:
On 10/20/2026 2:23 AM, Mikko wrote:
On 19/10/2026 17:34, olcott wrote:
On 10/19/2026 9:05 AM, Python wrote:What purpose would a DD that does not call HHH serve?
Peter,
I think your latest example makes the disagreement extremely precise: >>>>>
int main()
{
DD(); // is neither the input to HHH nor a finite static string
}
I completely agree with the comment.
DD() executing in main is NOT the input to HHH.
But the Halting Theorem does not require it to be.
DD cannot possibly do the opposite of whatever HHH
returns to it when DD is not the caller of HHH.
That DD() is incorrectly presumed to be the counter-example
input static finite string to the Halting Theorem.
Why would you incorrectly presume that the DD that does not call
HHH
would be a counter-example input static finite string to the
Halting Theorem?
(a) It is not an input it is the caller
(b) It is an executing process thus not a static finite string
The main shown above looks like a main function in C language.
If it really is then it calls some DD that is is a static finite
string in some some language (either C or a translation in some
other langage).
According to C rules a pointer to a function (like DD) can be
given as imput to a function but the function with that input
can only call the pointed function or determine wther it points
to the same function as another pointer. It cannot read the
finite string pointed to (unless there is a non-standard
implementation feature that permits such reading).
On 21/10/2026 17:15, olcott wrote:
On 10/21/2026 2:53 AM, Mikko wrote:
On 19/10/2026 17:19, olcott wrote:
On 10/19/2026 5:32 AM, Python wrote:
I think you are conflating three different things:
1. the finite representation of a program P,
The terminology is conventional and incorrect.
It never has had the indirect reference that
"representation of a program" has lead people
to believe.
(1) The term "description" is too vague. It never
has been any mere description it has always be a
100% completely specified sequence of steps.
In Turing's orignal article specified how the description shall
be encoded.
It misleading and in all my work henceforth called the
source code of a Turing Machine.
There is nothing misleading in Turings specification of the
standard description.
The term "souce code" does not specify the language.
A halting
decider needs be able to decide about every Turting machine,
regardless of the language of its orirginal presentation.
On 19/10/2026 18:56, olcott wrote:
On 10/19/2026 10:35 AM, Python wrote:Maybe it is, maybe not. You don't know, and neither does anybody else.
Peter,
When both of your own answers are wrong this proves
that I am correct.
No. It proves exactly the Halting Theorem.
You are overlooking what your program depends on.
Your 2004 example says:
if YOU say HALTS:
loop
else:
halt
So there is no answer that can be both:
1. supplied to the program, and
2. a correct prediction of the resulting behavior.
Agreed.
But that does not prove that halting is an "incorrect question".
On 6/23/2004 9:34 PM, Peter Olcott wrote:
;
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
;
Does this program Halt?
;
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
;
Please ONLY PROVIDE CORRECT ANSWERS!
I asked you for your answer and YOU failed.
This is NOT a fundamental limit to human reasoning
So far the limits of human reasoning are unknown.
But whatever the limits of human reasoning are, the unsolvability of
the halting problem is a limit to Turing computability and to all
known ways to compute.
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:The key mistake of the halting theorem is that
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 >>>
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* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
*Keeps repeating unless aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
On 10/23/2026 2:58 AM, Mikko wrote:
On 20/10/2026 17:29, olcott wrote:
On 10/20/2026 2:23 AM, Mikko wrote:
On 19/10/2026 17:34, olcott wrote:
On 10/19/2026 9:05 AM, Python wrote:What purpose would a DD that does not call HHH serve?
Peter,
I think your latest example makes the disagreement extremely precise: >>>>>>
int main()
{
DD(); // is neither the input to HHH nor a finite static >>>>>> string
}
I completely agree with the comment.
DD() executing in main is NOT the input to HHH.
But the Halting Theorem does not require it to be.
DD cannot possibly do the opposite of whatever HHH
returns to it when DD is not the caller of HHH.
That DD() is incorrectly presumed to be the counter-example
input static finite string to the Halting Theorem.
Why would you incorrectly presume that the DD that does not call
HHH
You must pay 100% complete attention to the exact meaning of
every single word that I say.
On 10/23/2026 3:06 AM, Mikko wrote:
On 21/10/2026 17:15, olcott wrote:
On 10/21/2026 2:53 AM, Mikko wrote:
On 19/10/2026 17:19, olcott wrote:
On 10/19/2026 5:32 AM, Python wrote:
I think you are conflating three different things:
1. the finite representation of a program P,
The terminology is conventional and incorrect.
It never has had the indirect reference that
"representation of a program" has lead people
to believe.
(1) The term "description" is too vague. It never
has been any mere description it has always be a
100% completely specified sequence of steps.
In Turing's orignal article specified how the description shall
be encoded.
It misleading and in all my work henceforth called the
source code of a Turing Machine.
There is nothing misleading in Turings specification of the
standard description.
That you have yet noticed. Dunning/Kruger
(1) It is no mere description, it is a 100% complete specification
(2) Is is not about some machine somewhere else it is source code
written in the Turing Machine programming language.
The term "souce code" does not specify the language.
The source code for Turing Machines is the Turing Machines
source code language. For functions written in C it is the
C programming language.
A halting
decider needs be able to decide about every Turting machine,
Not at all. It needs to apply relevant finite string inference
steps to its input computer programming source code.
On 10/23/2026 3:13 AM, Mikko wrote:
On 19/10/2026 18:56, olcott wrote:
On 10/19/2026 10:35 AM, Python wrote:Maybe it is, maybe not. You don't know, and neither does anybody else.
Peter,
When both of your own answers are wrong this proves
that I am correct.
No. It proves exactly the Halting Theorem.
You are overlooking what your program depends on.
Your 2004 example says:
if YOU say HALTS:
loop
else:
halt
So there is no answer that can be both:
1. supplied to the program, and
2. a correct prediction of the resulting behavior.
Agreed.
But that does not prove that halting is an "incorrect question".
On 6/23/2004 9:34 PM, Peter Olcott wrote:
;
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
;
Does this program Halt?
;
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
;
Please ONLY PROVIDE CORRECT ANSWERS!
I asked you for your answer and YOU failed.
This is NOT a fundamental limit to human reasoning
So far the limits of human reasoning are unknown.
The meaning of the words proves that the inability
to correctly answer an incorrect question that has
no correct answer is a short-coming of the question
and not the person asked.
On 10/23/2026 2:44 AM, Mikko wrote:
On 16/10/2026 16:28, olcott wrote:
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.
Axiom 1
--- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of
finite string transformation rules to finite string
inputs to derive any and all outputs.
Axiom 2
Computation requires correct rather than
arbitrary finite string transformations.
The brand new key insight that I had into the
foundations of computation is the notion of
{correct finite string transformations} as
opposed to and contrast with {arbitrary finite
string transformations}.
If we need to know the sum of 2 + 3 there seems
to be only a single sequence of finite string
transformation rules that derive this within
arithmetic operations on the integer type. This
is one concrete example of how computation is
limited to correct finite string transformations.
You are trying to deceive with tanother switch of topic.
The sum of 2 + 3 is a simple enough computation that
it is easily seen that relevant finite string
transformations are required to derive this sum
On the input: int X = sum(2,3);
int sum(int x, int y) { printf("Booyah!"); }
would not get the actual sum of 2 + 3
This simple example proves that finite string
transformation must be relevant to the computation.
This is more easily stated for deciders.
All of the finite string transformations must
be relevant to the decision criteria.
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*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
I.e., there is nothing about "DD()" or "main()", just as I said.
Though Linz says nothing about "embedded_H", either; that is
your own interpolation. And you omitted important parts of the
definition.
*Keeps repeating unless aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
No, that is not a part of the definition. And not a part of anything
else in Linz's book, either.
On 23/10/2026 17:26, olcott wrote:
On 10/23/2026 3:06 AM, Mikko wrote:
On 21/10/2026 17:15, olcott wrote:
On 10/21/2026 2:53 AM, Mikko wrote:
On 19/10/2026 17:19, olcott wrote:
On 10/19/2026 5:32 AM, Python wrote:
I think you are conflating three different things:
1. the finite representation of a program P,
The terminology is conventional and incorrect.
It never has had the indirect reference that
"representation of a program" has lead people
to believe.
(1) The term "description" is too vague. It never
has been any mere description it has always be a
100% completely specified sequence of steps.
In Turing's orignal article specified how the description shall
be encoded.
It misleading and in all my work henceforth called the
source code of a Turing Machine.
There is nothing misleading in Turings specification of the
standard description.
That you have yet noticed. Dunning/Kruger
That I haven't meatoned your Dunning/Kruger does not mean that
I had not noticed it. I just regard it as irrelevant.
(1) It is no mere description, it is a 100% complete specification
The problem statement clearly says "description".
Most formulation
leaves specification of the encoding rules to the solver of the
problem, so if the description is sufficiently complete the solver
has failed.
(2) Is is not about some machine somewhere else it is source code
written in the Turing Machine programming language.
As noted above, that is usually not a part of the problem specification.
The solver is free to require that or another way to describe.
The term "souce code" does not specify the language.
The source code for Turing Machines is the Turing Machines
source code language. For functions written in C it is the
C programming language.
There is no "the Turing Machine source code language".
The language
Turing origially used is more complicated than necessary. Therefore
most authors use a simpler language. They don't usually specify
every detail of the language because those deations are not relevant
to their purposes.
A halting
decider needs be able to decide about every Turting machine,
Not at all. It needs to apply relevant finite string inference
steps to its input computer programming source code.
From the meanings of the owrds follow that it it is not able to
decide about every Turing machine it is not a halting decider.
On 23/10/2026 17:31, olcott wrote:
On 10/23/2026 3:13 AM, Mikko wrote:
On 19/10/2026 18:56, olcott wrote:
On 10/19/2026 10:35 AM, Python wrote:Maybe it is, maybe not. You don't know, and neither does anybody else.
Peter,
When both of your own answers are wrong this proves
that I am correct.
No. It proves exactly the Halting Theorem.
You are overlooking what your program depends on.
Your 2004 example says:
if YOU say HALTS:
loop
else:
halt
So there is no answer that can be both:
1. supplied to the program, and
2. a correct prediction of the resulting behavior.
Agreed.
But that does not prove that halting is an "incorrect question".
On 6/23/2004 9:34 PM, Peter Olcott wrote:
;
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
;
Does this program Halt?
;
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
;
Please ONLY PROVIDE CORRECT ANSWERS!
I asked you for your answer and YOU failed.
This is NOT a fundamental limit to human reasoning
So far the limits of human reasoning are unknown.
The meaning of the words proves that the inability
to correctly answer an incorrect question that has
no correct answer is a short-coming of the question
and not the person asked.
That we can't tell what are the limits of human reasoning does not
mean that the question is incorrect. It simply means that we have
not yet found out all limits. People are still working on that and
may find out more, perhaps even all.
On 23/10/2026 17:15, olcott wrote:
On 10/23/2026 2:44 AM, Mikko wrote:
On 16/10/2026 16:28, olcott wrote:
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.
Axiom 1
--- Paraphrase of Emil Post definition of computation
All computations are equivalent to the application of
finite string transformation rules to finite string
inputs to derive any and all outputs.
Axiom 2
Computation requires correct rather than
arbitrary finite string transformations.
The brand new key insight that I had into the
foundations of computation is the notion of
{correct finite string transformations} as
opposed to and contrast with {arbitrary finite
string transformations}.
If we need to know the sum of 2 + 3 there seems
to be only a single sequence of finite string
transformation rules that derive this within
arithmetic operations on the integer type. This
is one concrete example of how computation is
limited to correct finite string transformations.
You are trying to deceive with tanother switch of topic.
The sum of 2 + 3 is a simple enough computation that
it is easily seen that relevant finite string
transformations are required to derive this sum
On the input: int X = sum(2,3);
int sum(int x, int y) { printf("Booyah!"); }
would not get the actual sum of 2 + 3
No, but in some situations what it does may be more inportant
than the sum of 2 and 3. For example, when a program that
needs the sum function does not behave as expected. The code
above can be used to determine when the program calls sum or
whther it does it at all.
This simple example proves that finite string
transformation must be relevant to the computation.
It is obvious even without a proof that at least some relevant
operation is needed. It does not tell what transformations
are needed or relevant or whther the set of necessary transformations
is unique. And nothing shows that an actual implementation must
use finite strings even if the description of the process may do.
This is more easily stated for deciders.
All of the finite string transformations must
be relevant to the decision criteria.
It is perfectly possible and perfectly legal to construct a
decider that performs irrelevant operations.
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.
On 10/23/2026 2:42 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 Ĥ.
This new machine takes as input WM, copies it,
and then behaves exactly like H'. Then the action
of Ĥ is such that
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.
</Linz text>
Irrelevant. The topic of the discussion woas the meaning of "halting
problem" which is already defined before the headline of theorem 12.1.
It is defined incoherently.
You don't pay close enough attention to see this.
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:The key mistake of the halting theorem is that
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 >>>
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* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
On 10/24/2026 3:14 AM, Mikko wrote:
On 23/10/2026 17:26, olcott wrote:
On 10/23/2026 3:06 AM, Mikko wrote:
On 21/10/2026 17:15, olcott wrote:
On 10/21/2026 2:53 AM, Mikko wrote:
On 19/10/2026 17:19, olcott wrote:
On 10/19/2026 5:32 AM, Python wrote:
I think you are conflating three different things:
1. the finite representation of a program P,
The terminology is conventional and incorrect.
It never has had the indirect reference that
"representation of a program" has lead people
to believe.
(1) The term "description" is too vague. It never
has been any mere description it has always be a
100% completely specified sequence of steps.
In Turing's orignal article specified how the description shall
be encoded.
It misleading and in all my work henceforth called the
source code of a Turing Machine.
There is nothing misleading in Turings specification of the
standard description.
That you have yet noticed. Dunning/Kruger
That I haven't meatoned your Dunning/Kruger does not mean that
I had not noticed it. I just regard it as irrelevant.
(1) It is no mere description, it is a 100% complete specification
The problem statement clearly says "description".
What was meany by that archaic language is the modern
idea of source code.
complete >> the solver has failed.Most formulation leaves specification of the encoding rules to the
solver of the problem, so if the description is sufficiently
Every program have a fixed constant programming language.
On 10/24/2026 3:18 AM, Mikko wrote:No, it is not. If two people are asked the same question and one cannot
On 23/10/2026 17:31, olcott wrote:
On 10/23/2026 3:13 AM, Mikko wrote:
On 19/10/2026 18:56, olcott wrote:
On 10/19/2026 10:35 AM, Python wrote:Maybe it is, maybe not. You don't know, and neither does anybody else. >>>> So far the limits of human reasoning are unknown.
Peter,
When both of your own answers are wrong this proves
that I am correct.
No. It proves exactly the Halting Theorem.
You are overlooking what your program depends on.
Your 2004 example says:
if YOU say HALTS:
loop
else:
halt
So there is no answer that can be both:
1. supplied to the program, and
2. a correct prediction of the resulting behavior.
Agreed.
But that does not prove that halting is an "incorrect question".
On 6/23/2004 9:34 PM, Peter Olcott wrote:
;
function LoopIfYouSayItHalts (bool YouSayItHalts):
if YouSayItHalts () then
while true do {}
else
return false;
;
Does this program Halt?
;
(Your (YES or NO) answer is to be considered
translated to Boolean as the function's input
parameter)
;
Please ONLY PROVIDE CORRECT ANSWERS!
I asked you for your answer and YOU failed.
This is NOT a fundamental limit to human reasoning
The meaning of the words proves that the inability
to correctly answer an incorrect question that has
no correct answer is a short-coming of the question
and not the person asked.
That we can't tell what are the limits of human reasoning does not
The inability to correctly answer an incorrect question
IS THE FAULT OF THE QUESTION
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 91:06:05 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
1,894 files (564M bytes) |
| Messages: | 2,551,613 |