On 10/7/2026 6:11 PM, Python wrote:
No, your new notion of "correct finite string transformations" still
does not prove it.
I can grant completely that every step performed by HHH must be a
correct finite-string transformation according to the operational
semantics of C.
This only leaves a single correct sequence for the DD
of HHH(DD) that shows that this DD cannot possibly reach
its own simulated final halt state.
We should be done at this point.
No, your new notion of "correct finite string transformations" still
does not prove it.
I can grant completely that every step performed by HHH must be a
correct finite-string transformation according to the operational
semantics of C.
What does NOT follow is:
therefore HHH can decide only properties of
behavior that occurs during those transformations.
Those are different statements.--
The transformations define HOW HHH computes.
The predicate
H(<P>,x) = HALTING iff P(x) halts
defines WHAT HHH is required to decide.
Nothing about requiring every computational step to be "correct" changes that distinction.
And this is not like proving "cats are not dogs". Your claim
a decider can only report on behavior that it actually sees
is a substantive restriction on computability. It is precisely the restriction on which your proposed correction of the Halting Problem depends.
So defining "correct transformations" does not prove it.
You still need the missing implication:
H uses only correct finite-string transformations
=>
H can decide only behavior occurring within
those transformations.
That implication is your theorem.
Please prove it rather than assuming it in the definition.
On 10/7/2026 6:11 PM, Python wrote:
No, your new notion of "correct finite string transformations" still
does not prove it.
I can grant completely that every step performed by HHH must be a
correct finite-string transformation according to the operational
semantics of C.
What does NOT follow is:
therefore HHH can decide only properties of
behavior that occurs during those transformations.
Only when you forget to apply Emil Post
// paraphrase of Emil Post
(1) All computations are essentially the application
of correct finite string transformation rules to
finite string inputs to derive any and all outputs.
(2) DD simulated by HHH applies the only correct
finite string transformation rules to its input DD.
(3) From (1) and (2) everything else that HHH can
possibly do is incorrect.
(4) The DD from (2) cannot possibly reach its own
final halt state.
(5) Therefore from (4) HHH is correct to reject its
input DD as non-halting.
Le 08/10/2026 à 14:41, olcott a écrit :
On 10/7/2026 6:11 PM, Python wrote:
No, your new notion of "correct finite string transformations" still
does not prove it.
I can grant completely that every step performed by HHH must be a
correct finite-string transformation according to the operational
semantics of C.
What does NOT follow is:
therefore HHH can decide only properties of
behavior that occurs during those transformations.
Only when you forget to apply Emil Post
// paraphrase of Emil Post
(1) All computations are essentially the application
of correct finite string transformation rules to
finite string inputs to derive any and all outputs.
(2) DD simulated by HHH applies the only correct
finite string transformation rules to its input DD.
(3) From (1) and (2) everything else that HHH can
possibly do is incorrect.
(4) The DD from (2) cannot possibly reach its own
final halt state.
(5) Therefore from (4) HHH is correct to reject its
input DD as non-halting.
Now the exact invalid inference is visible.
I grant (1), (2), and (4) for the sake of argument.
But (3) does NOT follow from (1) and (2):
(2) DD simulated by HHH follows the only correct
sequence of C transitions.
does not imply:
(3) therefore every other property HHH might
decide about DD is incorrect.
You have changed the meaning of "correct".
In (2), "correct" means:
correct execution/simulation steps.
In (3), it suddenly means:
the only property HHH is permitted to decide.
Those are not the same proposition.--
And consequently (5) also overreaches. From (4) you may conclude:
HHH's simulated DD does not reach its simulated halt state.
You cannot simply replace that with:
DD is non-halting.
That is exactly the semantic bridge we have been discussing.
So Emil Post does not repair the gap.
The gap is now literally between your lines (2) and (3).
On 10/8/2026 7:48 AM, Python wrote:
Le 08/10/2026 à 14:41, olcott a écrit :
On 10/7/2026 6:11 PM, Python wrote:
No, your new notion of "correct finite string transformations" still
does not prove it.
I can grant completely that every step performed by HHH must be a
correct finite-string transformation according to the operational
semantics of C.
What does NOT follow is:
therefore HHH can decide only properties of
behavior that occurs during those transformations.
Only when you forget to apply Emil Post
// paraphrase of Emil Post
(1) All computations are essentially the application
of correct finite string transformation rules to
finite string inputs to derive any and all outputs.
(2) DD simulated by HHH applies the only correct
finite string transformation rules to its input DD.
(3) From (1) and (2) everything else that HHH can
possibly do is incorrect.
(4) The DD from (2) cannot possibly reach its own
final halt state.
(5) Therefore from (4) HHH is correct to reject its
input DD as non-halting.
Now the exact invalid inference is visible.
I grant (1), (2), and (4) for the sake of argument.
But (3) does NOT follow from (1) and (2):
(2) DD simulated by HHH follows the only correct
sequence of C transitions.
does not imply:
(3) therefore every other property HHH might
decide about DD is incorrect.
(3) From (1) and (2) everything else that HHH can
possibly do (within the same context) is incorrect.
(3) From (1) and (2) everything else that HHH can
possibly do [to determine the behavior that its
finite string input DD specifies] is incorrect.
You have changed the meaning of "correct".
In (2), "correct" means:
correct execution/simulation steps.
In (3), it suddenly means:
the only property HHH is permitted to decide.
That is outside of the context of the whole discussion.
Context and compositional semantics determine the full
meaning of an expression of language. You simply ignored
context.
The resulting update is clearer now though and that is a
good thing. My whole purpose of dialogue is to maximize
clarity.
Those are not the same proposition.
And consequently (5) also overreaches. From (4) you may conclude:
HHH's simulated DD does not reach its simulated halt state.
You cannot simply replace that with:
DD is non-halting.
That is exactly the semantic bridge we have been discussing.
So Emil Post does not repair the gap.
The gap is now literally between your lines (2) and (3).
Le 08/10/2026 à 17:37, olcott a écrit :
Yes, the clarification makes (3) better:
everything else that HHH can possibly do
[to determine the behavior that its finite string
input DD specifies] is incorrect.
But now the entire issue is hidden in the word:
"specifies"
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
What you have NOT established is:
therefore this recursive simulation is the ONLY
behavior that the finite string DD "specifies".
That is precisely the disputed proposition.
The standard halting predicate interprets the finite description DD as specifying the computation DD().
You interpret the same finite description, when supplied to HHH, as specifying only HHH's recursively nested simulation of DD.
So adding:
"to determine the behavior that its finite
string input DD specifies"
does not derive your conclusion.
It embeds the missing conclusion inside the definition of "specifies".
The question therefore remains exactly the same:
Why does the finite string DD cease to specify DD()
merely because DD is being examined by HHH?
Until that is proved, (3) still does not follow from (1) and (2).
No. Even granting (1), (2), (3), and (4) exactly as you now state them,
(5) still does not follow.
Your (4) says:
The DD from (3) cannot possibly reach its own
final halt state.
But "the DD from (3)" is explicitly:
DD correctly simulated by HHH.
So (4) establishes:
DD correctly simulated by HHH does not halt.
Agreed.
Then (5) changes this into:
HHH is correct to reject its input DD as non-halting.
That is a different proposition.
You previously insisted that I must NOT paraphrase
[the correctly simulated] DD specifies a
non-halting sequence of configurations
as
DD does not halt.
I accepted that correction.
But (5) now makes essentially that same jump yourself.
The Sipser-compatible conclusion from (4) is:
HHH may report that [the correctly simulated] DD
specifies a non-halting sequence of configurations.
It is NOT yet:
therefore DD is non-halting.
So even if I grant your rewritten (1)-(4) completely, the logical gap remains between (4) and (5).
Calling (1)-(4) "self-evidently true axioms" cannot supply that missing implication.
Fair enough. With your explicit insertion of "[simulated]", I withdraw
my objection to (4) -> (5).
So we can agree:
HHH is correct to reject its [simulated] input DD
as non-halting.
But notice what we have now established — and only that.
We have NOT established:
DD() is non-halting.
Indeed, we agree that DD() returns when HHH returns 0.--
So your corrected (5) is perfectly compatible with:
simulated DD within HHH: non-halting
actual DD(): halting
That brings us straight back to the central question.
Why is a halt decider required to classify only the first, rather than decide whether the computation specified by DD halts?
Your insertion of "[simulated]" fixes (5), but it also makes explicit
that HHH is deciding the behavior of its simulation.
It does not prove that this is the standard halting predicate.
That remains the missing step.
No, Peter. That is precisely the proposition we have NOT established.
You assert:
Requiring HHH to decide whether DD() halts
violates the Emil Post definition of computation.
But why?
The INPUT to HHH is a finite string encoding DD.
The OUTPUT is a finite accept/reject result.
HHH itself performs only finite-string transformations.
Nothing in that description violates your Post criterion.
The fact that the PROPERTY being decided concerns the computation DD()--
does not make DD() an additional input to HHH.
That is the distinction you keep collapsing:
what HHH COMPUTES WITH:
finite strings
what HHH DECIDES ABOUT:
the computation encoded by those finite strings.
Post constrains the former. You have not shown that it constrains the
latter in the way you claim.
So please don't say "we already established" this.
Give the actual implication:
finite-string transformations on finite-string inputs
=>
cannot decide whether the computation encoded
by those strings halts.
THAT is your claimed correction to the Halting Problem.
And THAT is what remains unproved.
On 10/9/2026 11:45 AM, Python wrote:
No, Peter. That is precisely the proposition we have NOT established.
You assert:
Requiring HHH to decide whether DD() halts
violates the Emil Post definition of computation.
But why?
The INPUT to HHH is a finite string encoding DD.
The OUTPUT is a finite accept/reject result.
HHH itself performs only finite-string transformations.
Nothing in that description violates your Post criterion.
You must pay 100% complete attention to every single word.
You must pay 100% complete attention to every single word.
You must pay 100% complete attention to every single word.
You must pay 100% complete attention to every single word.
// paraphrase of Emil Post
(1) All computations are essentially the application
of finite string transformation rules to finite string
inputs to derive any and all outputs.
(2) Correct finite string transformation rules for
HHH(DD) are specified by the operational semantics
of the C programming language.
(3) From (2) DD correctly simulated by HHH is the
only set of correct finite string transformation
rules for HHH(DD). This entails that every other
finite string transformation is incorrect for HHH(DD).
(4) The DD from (3) cannot possibly reach its own
final halt state.
(5) Therefore from (1)(2)(3)(4) HHH is correct to
reject its DD input.
Le 09/10/2026 à 19:01, olcott a écrit :
On 10/9/2026 11:45 AM, Python wrote:
No, Peter. That is precisely the proposition we have NOT established.
You assert:
Requiring HHH to decide whether DD() halts
violates the Emil Post definition of computation.
But why?
The INPUT to HHH is a finite string encoding DD.
The OUTPUT is a finite accept/reject result.
HHH itself performs only finite-string transformations.
Nothing in that description violates your Post criterion.
You must pay 100% complete attention to every single word.
You must pay 100% complete attention to every single word.
You must pay 100% complete attention to every single word.
You must pay 100% complete attention to every single word.
// paraphrase of Emil Post
(1) All computations are essentially the application
of finite string transformation rules to finite string
inputs to derive any and all outputs.
(2) Correct finite string transformation rules for
HHH(DD) are specified by the operational semantics
of the C programming language.
(3) From (2) DD correctly simulated by HHH is the
only set of correct finite string transformation
rules for HHH(DD). This entails that every other
finite string transformation is incorrect for HHH(DD).
(4) The DD from (3) cannot possibly reach its own
final halt state.
(5) Therefore from (1)(2)(3)(4) HHH is correct to
reject its DD input.
I am paying attention to every word.
So let's grant (1)-(5) EXACTLY as you wrote them.
Then your conclusion is:
HHH is correct to reject its DD input
in the sense we just agreed upon:
DD correctly simulated by HHH does not reach
its simulated final halt state.
AGREED.
Now point to the line in (1)-(5) that proves:
Asking whether DD() halts violates the
Emil Post definition of computation.
There isn't one.
(1) says how computations operate.--
(2)-(4) describe HHH's simulation.
(5) classifies that simulation.
None of them proves that a computation operating on the finite string DD cannot be required to decide a property of the computation encoded by DD.
So repeating (1)-(5) cannot answer the objection.
I accept (1)-(5).
Now derive the proposition you actually need:
finite-string computation
=>
cannot decide whether the computation encoded
by its finite-string input halts.
Please show that implication from (1)-(5), without simply asserting it.
That is the missing proof.
On 10/7/2026 5:46 AM, Mikko wrote:
On 02/10/2026 17:15, olcott wrote:
On 10/2/2026 8:58 AM, Python wrote:
Le 02/10/2026 à 15:56, olcott a écrit :
On 10/2/2026 8:32 AM, Python wrote:
Le 02/10/2026 à 15:24, olcott a écrit :It has taken me many thousands of hours very carefully
On 10/2/2026 7:59 AM, Python wrote:
Le 02/10/2026 à 14:28, olcott a écrit :
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()
https://github.com/plolcott/x86utm/blob/master/README.md
This is outside of the Church-Turing scope when this scope
is understood to only allow finite string transformation
rules to be applied to finite string inputs to derive any
any all outputs.
The only correct finite string transformation rules that
HHH is allowed to apply to its finite string input DD are
specified by the operational semantics of the C programming
language.
There are no correct finite string transformation rules that >>>>>>>>> HHH can possibly apply to its input finite string that derive >>>>>>>>> the behavior of DD directly executed in main().
Peter, this distinction between "the operational semantics of C" >>>>>>>> and "the behavior of DD directly executed from main()" does not >>>>>>>> exist.
Counter-factual you just did not pay close enough
attention and merely leaped to a false conclusion.
Peter, saying "counter-factual" is not a counterargument.
compose the few words that I just said. Carefully
study them for a few hours until you fully understand
every subtle nuance of every single detail before you
reply.
Peter, the number of hours you spent composing a statement has no
bearing on whether it is true.
That is true, None-the-less I will no longer
tolerate people that glance at a couple of
my words before artificially contriving a
rebuttal that conclusively proves that they
did not bother to pay complete attention
to every detail of what I said.
So you are not going to tolerate reasonable people
Python has proved to be the most reasonable person that
ever reviewed my work. Go look at our whole recent exchange.
olcott wrote:
On 10/7/2026 4:27 PM, Python wrote:
No, Peter. I am not missing that point. I am rejecting it.
You keep asserting:
A halt decider can only report on the behavior
that it actually sees.
That is precisely the proposition you need to prove.
It is proven completely true entirely on the basis of
the meaning of its words. How do you "prove" that
"cats are not dogs"?
Why prove it? Aren't 'cats' and 'dogs' well-defined in your query?
On 08/10/2026 01:25, Blaine wrote:
olcott wrote:
On 10/7/2026 4:27 PM, Python wrote:
No, Peter. I am not missing that point. I am rejecting it.
You keep asserting:
A halt decider can only report on the behavior
that it actually sees.
That is precisely the proposition you need to prove.
It is proven completely true entirely on the basis of
the meaning of its words. How do you "prove" that
"cats are not dogs"?
Why prove it? Aren't 'cats' and 'dogs' well-defined in your query?
Is a bobcat a cat ?
The requested proof would compare the meanings of "cat" and "dog" and identifies some essential feature that every can has but no dog and
another essential feature that every dog has but no cat.
You are still conflating SIMULATION with DECISION.
These are different operations:--
SIMULATE DD:
Generate DD's configurations step by step
according to the C operational semantics.
DECIDE HALT(DD):
Compute one bit:
does the computation specified by DD halt?
A halt decider is required to do the second.
It is NOT required to obtain that bit by completing the first.
So I grant your new statement completely:
HHH's recursive simulation does not derive
the behavior of DD() executed from main().
But this tells us only something about that SIMULATION.
It does not imply:
no finite-string computation can DECIDE
whether DD() halts.
That implication is exactly what the Halting Theorem says is impossible
in general — and what you must prove independently if you claim the theorem's specification itself is invalid.
Put even more simply:
failure to SIMULATE a behavior to completion
is not the same proposition as:
impossibility of DECIDING a property of that behavior.
Your argument establishes the former and then silently substitutes the latter.
That is the gap.
You are still conflating SIMULATION with DECISION.
These are different operations:
SIMULATE DD:
Generate DD's configurations step by step
according to the C operational semantics.
DECIDE HALT(DD):
Compute one bit:
does the computation specified by DD halt?
A halt decider is required to do the second.
It is NOT required to obtain that bit by completing the first.
So I grant your new statement completely:
HHH's recursive simulation does not derive
the behavior of DD() executed from main().
But this tells us only something about that SIMULATION.
It does not imply:
no finite-string computation can DECIDE
whether DD() halts.
That implication is exactly what the Halting Theorem says is impossible
in general — and what you must prove independently if you claim the theorem's specification itself is invalid.
Put even more simply:
failure to SIMULATE a behavior to completion
is not the same proposition as:
impossibility of DECIDING a property of that behavior.
Your argument establishes the former and then silently substitutes the latter.
That is the gap.
On 10/10/2026 1:32 AM, Python wrote:
You are still conflating SIMULATION with DECISION.
These are different operations:
SIMULATE DD:
Generate DD's configurations step by step
according to the C operational semantics.
DECIDE HALT(DD):
Compute one bit:
does the computation specified by DD halt?
A halt decider is required to do the second.
It is NOT required to obtain that bit by completing the first.
It turns out that it is.
No one ever bothered to notice this before because
they abstracted away the important part that my
fully concrete code reveals.
So I grant your new statement completely:
HHH's recursive simulation does not derive
the behavior of DD() executed from main().
But this tells us only something about that SIMULATION.
It does not imply:
no finite-string computation can DECIDE
whether DD() halts.
That is a bad paraphrase.
HHH1(DD) does decide the same behavior as DD()
executed from main() and it does this by applying
the same correct finite string transformation rules.
That implication is exactly what the Halting Theorem says is
impossible in general — and what you must prove independently if you
claim the theorem's specification itself is invalid.
The halting theorem says that there are "inputs"
(that never were actual inputs) that do the
opposite of whatever value their decider returns.
It has always been a mistake to require a halt
decider to report on the behavior of its own
caller. The Peter Linz Turing Machine based proof
makes this exact same mistake.
What I love about his proof over all others is that
he makes everything 100% concrete as specific state
transitions.
Put even more simply:
failure to SIMULATE a behavior to completion
That is just you not paying 100% complete attention to
every single word.
When HHH applies the only possible sequence of correct
finite string transformations to its finite string
input this input never reaches its own final halt
state whether or not HHH ever aborts its simulation.
is not the same proposition as:
impossibility of DECIDING a property of that behavior.
Yes as I have shown that HHH does correctly decide the
halting property of its input finite string.
Your argument establishes the former and then silently substitutes the
latter.
That is the gap.
https://github.com/plolcott/x86utm/blob/master/README.md
That is the result of 50,000 rewrites since 2004. All of
them are still out there on comp.theory.
Try and spend 30 minutes (1/40,000-th of the 20,000 hours that I spent) reading and re-reading that.
I read the README carefully.
And your HHH1 example actually makes my objection sharper.
You now say:
HHH1(DD) decides the same behavior as DD()
executed from main().
Good.
Then that behavior is plainly NOT outside the scope of computation
merely because DD is supplied as a finite-string input.
So we now have two different computations:
HHH(DD)
performs recursive simulation S
and decides a property of S.
HHH1(DD)
performs different finite-string transformations
and, according to you, decides whether DD() halts.
That demonstrates exactly the distinction I have been making.
The sequence of transformations performed by HHH determines HOW HHH computes.
It does not, merely by being HHH's unique simulation sequence, establish WHAT semantic property a halt decider is allowed to decide.
Your README makes the unsupported step explicit:
"This sequence does not derive the behavior
of DD() executed from main()."
followed by:
"HHH cannot report on the behavior of its
caller DD()."
The second statement does not follow from the first.
And HHH1 makes that particularly obvious: by your own account, a finite- string computation CAN decide the halting behavior of DD().
So the issue is no longer whether DD() is somehow outside Emil Post computation. By your own HHH1 example, it isn't.
The issue is simply whether HHH computes the standard halting predicate.
If HHH only answers:
"Does my recursively simulated DD reach
its simulated halt state?"
then HHH may answer that correctly.
But that is a different predicate from:
"Does the computation DD() halt?"
Calling the first one a "halt decider" does not make the two predicates identical.--
This sentence finally isolates our disagreement:
"That predicate has always violated Axiom 1
for all inputs."
No. Axiom 1 says:
computation = finite-string transformations
applied to finite-string inputs.
The predicate
HALT(<P>, x) = "does P(x) halt?"
does not violate that.
<P> and x are finite strings.
The decider receives those finite strings.
It performs finite-string transformations.
It returns a finite answer.
Nothing in Axiom 1 says that the property being decided must be--
identical to the behavior generated during the decider's own simulation.
You have added that restriction yourself.
And this:
"HHH has no idea who its caller is"
is irrelevant.
A halt decider is not asked:
"Who called me?"
It is asked:
"Does the computation encoded by my input halt?"
In the diagonal construction, the relevant program is encoded in the
input. It does not have to be discovered by inspecting the runtime caller.
So PSR may certainly cause:
HHH(DD) -> simulation sequence A
HHH1(DD) -> simulation sequence B
I grant that completely.
But from that you still cannot derive:
therefore HALT(<DD>) is an invalid predicate.
Axiom 1 constrains HOW a computation computes.
You are adding, without proof, a new axiom constraining WHAT a
computation may compute:
Axiom 1A:
A decider may only decide properties of the
particular execution sequence it generates internally.
That statement is nowhere in Axiom 1.
And your entire conclusion now depends on Axiom 1A, not Axiom 1.
This sentence finally isolates our disagreement:
"That predicate has always violated Axiom 1
for all inputs."
No. Axiom 1 says:
computation = finite-string transformations
applied to finite-string inputs.
The predicate
HALT(<P>, x) = "does P(x) halt?"
does not violate that.
<P> and x are finite strings.
The decider receives those finite strings.
It performs finite-string transformations.
It returns a finite answer.
Nothing in Axiom 1 says that the property being decided must be
identical to the behavior generated during the decider's own simulation.
You have added that restriction yourself.
And this:
"HHH has no idea who its caller is"
is irrelevant.
A halt decider is not asked:
"Who called me?"
It is asked:
"Does the computation encoded by my input halt?"
In the diagonal construction, the relevant program is encoded in the
input. It does not have to be discovered by inspecting the runtime caller.
So PSR may certainly cause:
HHH(DD) -> simulation sequence A
HHH1(DD) -> simulation sequence B
I grant that completely.
But from that you still cannot derive:
therefore HALT(<DD>) is an invalid predicate.
Axiom 1 constrains HOW a computation computes.
You are adding, without proof, a new axiom constraining WHAT a
computation may compute:
Axiom 1A:
A decider may only decide properties of the
particular execution sequence it generates internally.
That statement is nowhere in Axiom 1.
And your entire conclusion now depends on Axiom 1A, not Axiom 1.
Fine. Let's stop exactly there.
You object to my writing HALT because HALT is a mathematical function
rather than an implementation.
That distinction is standard and essential:
HALT(<P>) = the mathematical predicate to be decided
HHH(<P>) = a computation proposed to decide it
The whole question is whether HHH computes HALT.
But I am happy to use only your terminology for the moment:
HHH(<DD>) =
"Does the <DD> input to HHH specify the halt property?"
Now we have isolated the crucial word:
"specify"
What exactly does that mean?
There are two very different possibilities:
(A) <DD> specifies the computation described by the C source DD.
or
(B) <DD> specifies only the sequence generated when HHH
recursively simulates DD.
Under (A), DD() returns when HHH(DD) returns 0.
Under (B), you get your non-halting recursive simulation.
But Axiom 1 says only that computations transform finite strings.
Axiom 2 says which transformations correctly implement C semantics.
Neither says that "the computation specified by <DD>" changes from (A)
to (B) merely because HHH is examining <DD>.
So before proceeding, please define "specify" precisely.
Because if "specify" means "the behavior produced by HHH's recursive simulation", then your conclusion is already built into your definition.
And that would not be a proof that the conventional halting predicate is invalid. It would simply be the definition of a different predicate.--
Your new Generic Axiom 2 finally states explicitly the additional restriction I have been asking you to identify:
The only correct finite-string transformations
that H may apply to D are those specified by
the operational semantics of D's source language.
So I no longer need to ask where that restriction comes from.
You have introduced it as a NEW AXIOM.
Now the entire issue reduces to whether Generic Axiom 2 is true.
Operational semantics tells us how execution of D proceeds.
It does not normally say that a program analyzing D may perform ONLY transformations corresponding to execution steps of D.
For example, an analyzer may parse D, construct a control-flow graph, perform abstract interpretation, prove an invariant, or recognize a syntactic special case. Those are computations on the finite
representation of D, but they are not execution steps of D.
So Generic Axiom 2 is much stronger than:
"correct simulation of D must obey the
operational semantics of D."
That statement I accept.
Your new axiom says instead:
"every correct computation by a halt decider
about D must be restricted to transformations
specified by D's operational semantics."
That is precisely the additional proposition your argument requires.
So we have finally isolated the disagreement:
I accept Axiom 1.
I accept that a correct SIMULATION must obey
the operational semantics.
I do NOT accept Generic Axiom 2.
It now needs a proof.
And it cannot be justified merely by calling its permitted--
transformations "correct", because that would make the axiom true by definition and therefore assume the very restriction your argument is intended to prove.
On 10/13/2026 7:45 AM, Python wrote:
Fine. Let's stop exactly there.
You object to my writing HALT because HALT is a mathematical function
rather than an implementation.
That distinction is standard and essential:
HALT(<P>) = the mathematical predicate to be decided
HHH(<P>) = a computation proposed to decide it
The whole question is whether HHH computes HALT.
That blurs together key distinctions that must remain separate.
Exactly — HHH cannot correctly SIMULATE DD by pretending line 03 jumps directly to line 06.
Agreed.
But that proves a constraint on SIMULATION, not on DECISION.
Consider this perfectly valid decider:
H(P):
if P is exactly "int main() { return 0; }"
return HALTS;
otherwise
return UNKNOWN;
It correctly decides halting for that one program without executing even
one of its C transitions.
It does not "guess" that execution skips anything. It simply analyzes
the finite string.
Therefore:
correct simulation must follow operational semantics
does NOT imply:
every correct decision must proceed by simulation.
Your Generic Axiom 2 asserts the second.
Your line-03/line-06 example establishes only the first.
That is still the missing implication.
On 2026-10-13 07:10, olcott wrote:
On 10/13/2026 7:45 AM, Python wrote:
Fine. Let's stop exactly there.
You object to my writing HALT because HALT is a mathematical function
rather than an implementation.
That distinction is standard and essential:
HALT(<P>) = the mathematical predicate to be decided
HHH(<P>) = a computation proposed to decide it
The whole question is whether HHH computes HALT.
That blurs together key distinctions that must remain separate.
How exactly does making a distinction explicit constitute 'bluring' the distinction? It seems to me that it is you who blurs this distinction.
André
On 10/13/2026 10:15 PM, André G. Isaak wrote:
On 2026-10-13 07:10, olcott wrote:
On 10/13/2026 7:45 AM, Python wrote:
Fine. Let's stop exactly there.
You object to my writing HALT because HALT is a mathematical
function rather than an implementation.
That distinction is standard and essential:
HALT(<P>) = the mathematical predicate to be decided
HHH(<P>) = a computation proposed to decide it
The whole question is whether HHH computes HALT.
That blurs together key distinctions that must remain separate.
How exactly does making a distinction explicit constitute 'bluring'
the distinction? It seems to me that it is you who blurs this
distinction.
André
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are eqivalent to the application of finite string transformation rules to finite string inputs to derive any and all
outputs.
The rest of this proof will be restricted to the above model
of computation thus: All computations are only allowed to apply
finite string transformations to their finite string inputs.
Axiom 2
The brand new key insight that I had into the foundations of
computation applied to halt deciders is the notion of "correct" as
opposed to and contrast with "arbitrary" finite string transformations.
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.
HHH cannot correctly guess that DD will ignore its own line
03 and leap to its own line 06
Generic Axiom 2
The only correct finite string transformation rules that a halt
decider H is allowed to apply to its finite string input D are
specified strictly by the operational semantics of the source
language of the computation. This applies universally to all
models of computation, including the source code of Turing
Machines.
On 2026-10-13 21:45, olcott wrote:
On 10/13/2026 10:15 PM, André G. Isaak wrote:
On 2026-10-13 07:10, olcott wrote:
On 10/13/2026 7:45 AM, Python wrote:
Fine. Let's stop exactly there.
You object to my writing HALT because HALT is a mathematical
function rather than an implementation.
That distinction is standard and essential:
HALT(<P>) = the mathematical predicate to be decided
HHH(<P>) = a computation proposed to decide it
The whole question is whether HHH computes HALT.
That blurs together key distinctions that must remain separate.
How exactly does making a distinction explicit constitute 'bluring'
the distinction? It seems to me that it is you who blurs this
distinction.
André
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are eqivalent to the application of finite string
transformation rules to finite string inputs to derive any and all
outputs.
The rest of this proof will be restricted to the above model
of computation thus: All computations are only allowed to apply
finite string transformations to their finite string inputs.
Axiom 2
The brand new key insight that I had into the foundations of
computation applied to halt deciders is the notion of "correct" as
opposed to and contrast with "arbitrary" finite string transformations.
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.
The halting problem makes no mention of simulation. It asks whether it
is possible to construct a Turing Machine which computes the
mathematical HALT function.
Since you seem to believe that this is not
possible (though for perverse reasons unrelated to reality), you seem to
be agreeing with the consensus on the topic. If HHH() does not compute
the HALT function, then it is not a halt decider.
André
HHH cannot correctly guess that DD will ignore its own line
03 and leap to its own line 06
Generic Axiom 2
The only correct finite string transformation rules that a halt
decider H is allowed to apply to its finite string input D are
specified strictly by the operational semantics of the source
language of the computation. This applies universally to all
models of computation, including the source code of Turing
Machines.
André has identified exactly the same gap I have.
Axiom 1:
computation operates by finite-string transformations.
Agreed.
But Generic Axiom 2 adds:
a halt decider must SIMULATE its input according
to the input program's operational semantics.
That does not follow from Axiom 1.
Consider:
H(P):
if P is exactly "int main() { return 0; }"
return HALTS;
otherwise
return UNKNOWN;
H correctly decides that this particular P halts by inspecting its finite-string input. It performs no C execution step and no simulation.
So the distinction between "correct" and "arbitrary" transformations
does not establish Generic Axiom 2.
The transformation above is correct precisely because its answer is
correct.
You have shown that a correct SIMULATION must respect operational--
semantics.
You have not shown that a correct DECISION must be a simulation.
That is the entire issue.
On 10/13/2026 10:56 PM, André G. Isaak wrote:
On 2026-10-13 21:45, olcott wrote:
On 10/13/2026 10:15 PM, André G. Isaak wrote:
On 2026-10-13 07:10, olcott wrote:
On 10/13/2026 7:45 AM, Python wrote:
Fine. Let's stop exactly there.
You object to my writing HALT because HALT is a mathematical
function rather than an implementation.
That distinction is standard and essential:
HALT(<P>) = the mathematical predicate to be decided
HHH(<P>) = a computation proposed to decide it
The whole question is whether HHH computes HALT.
That blurs together key distinctions that must remain separate.
How exactly does making a distinction explicit constitute 'bluring'
the distinction? It seems to me that it is you who blurs this
distinction.
André
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are eqivalent to the application of finite string
transformation rules to finite string inputs to derive any and all
outputs.
The rest of this proof will be restricted to the above model
of computation thus: All computations are only allowed to apply
finite string transformations to their finite string inputs.
Axiom 2
The brand new key insight that I had into the foundations of
computation applied to halt deciders is the notion of "correct" as
opposed to and contrast with "arbitrary" finite string transformations.
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.
The halting problem makes no mention of simulation. It asks whether it
is possible to construct a Turing Machine which computes the
mathematical HALT function.
The foundations of computation accept this:
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.
No one besides me ever distinguished the difference
between [correct finite string transformations] and
[arbitrary finite string transformations].
Since you seem to believe that this is not possible (though for
perverse reasons unrelated to reality), you seem to be agreeing with
the consensus on the topic. If HHH() does not compute the HALT
function, then it is not a halt decider.
André
HHH cannot correctly guess that DD will ignore its own line
03 and leap to its own line 06
Generic Axiom 2
The only correct finite string transformation rules that a halt
decider H is allowed to apply to its finite string input D are
specified strictly by the operational semantics of the source
language of the computation. This applies universally to all
models of computation, including the source code of Turing
Machines.
That does not rescue Generic Axiom 2.
Suppose I did simulate one example in my head while designing H.
My mind is not part of the computation H(P).
Axiom 1 concerns the finite-string transformations actually performed by
the computation.
For:
P = "int main() { return 123; }"
H can perform:
1. Parse P.
2. Prove syntactically that its body consists of an unconditional return.
3. Return HALTS.
H never generates P's execution sequence.
Calling some reasoning performed by H's designer "simulation" does not
turn H's transformations into operational-semantic simulation steps.
Otherwise I could write:
H(P):
mechanically prove theorem T(P)
if T(P) proves termination: return HALTS
and you could always reply:
"Someone must have simulated P in their head."
That is not a property of H(P). It is a story about how H was invented.
Your Generic Axiom 2 is a claim about
what H is allowed to COMPUTE.
So its justification must concern H's computation, not computations allegedly performed in the programmer's head.
The distinction remains:
proving a property of an execution
!=
performing that execution.
Until you establish otherwise, Generic Axiom 2 is an assumption, not a refutation of the Halting Theorem.
On 2026-10-14 06:39, olcott wrote:
On 10/13/2026 10:56 PM, André G. Isaak wrote:
On 2026-10-13 21:45, olcott wrote:
On 10/13/2026 10:15 PM, André G. Isaak wrote:
On 2026-10-13 07:10, olcott wrote:
On 10/13/2026 7:45 AM, Python wrote:
Fine. Let's stop exactly there.
You object to my writing HALT because HALT is a mathematical
function rather than an implementation.
That distinction is standard and essential:
HALT(<P>) = the mathematical predicate to be decided
HHH(<P>) = a computation proposed to decide it
The whole question is whether HHH computes HALT.
That blurs together key distinctions that must remain separate.
How exactly does making a distinction explicit constitute 'bluring' >>>>> the distinction? It seems to me that it is you who blurs this
distinction.
André
Axiom 1 --- Paraphrase of Emil Post definition of computation
All computations are eqivalent to the application of finite string
transformation rules to finite string inputs to derive any and all
outputs.
The rest of this proof will be restricted to the above model
of computation thus: All computations are only allowed to apply
finite string transformations to their finite string inputs.
Axiom 2
The brand new key insight that I had into the foundations of
computation applied to halt deciders is the notion of "correct" as
opposed to and contrast with "arbitrary" finite string transformations. >>>>
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.
The halting problem makes no mention of simulation. It asks whether
it is possible to construct a Turing Machine which computes the
mathematical HALT function.
The foundations of computation accept this:
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.
No one besides me ever distinguished the difference
between [correct finite string transformations] and
[arbitrary finite string transformations].
Even if I were to accept your axioms, it's not clear to me exactly what
they have to do with the point which I was making which was about how
the halting problem is actually defined.
It asks whether it is possible
to construct a TM which computes the /mathematical/ halt function. If it
is not possible, /for whatever reason/, then the answer to the halting problem is "no".
André
Since you seem to believe that this is not possible (though for
perverse reasons unrelated to reality), you seem to be agreeing with
the consensus on the topic. If HHH() does not compute the HALT
function, then it is not a halt decider.
André
HHH cannot correctly guess that DD will ignore its own line
03 and leap to its own line 06
Generic Axiom 2
The only correct finite string transformation rules that a halt
decider H is allowed to apply to its finite string input D are
specified strictly by the operational semantics of the source
language of the computation. This applies universally to all
models of computation, including the source code of Turing
Machines.
Peter, we have finally reduced this to one sentence:
"The single requirement of correct finite string
transformations ... refutes the Halting Theorem."
But "correct" is doing all the work.
In standard computability, a transformation is correct for a decision problem if it computes the specified answer correctly.
In your argument, "correct" means:
restricted to the transformations permitted
by your Generic Axiom 2.
Then you conclude that any decision procedure not satisfying Generic
Axiom 2 is incorrect.
That is circular.
And your reply to André makes the issue explicit:
"The Halting Problem was defined with insufficient detail.
When we add my detail..."
Exactly.
You are ADDING a restriction to the Halting Problem.
The classical question is:
Does any computation decide whether P(x) halts?
Your modified question is:
Does any computation decide whether P(x) halts
while obeying my additional restrictions
on how
that decision may be obtained?
Showing that the answer to the second question differs from the first
does not refute the Halting Theorem.
It defines a different problem.
So there is now only one thing left to prove:
Why is Generic Axiom 2 a necessary property of
computation, rather than an additional restriction
you have imposed on halt deciders?
Repeating the word "correct" cannot provide that proof.
On 10/14/2026 8:47 AM, André G. Isaak wrote:
Even if I were to accept your axioms, it's not clear to me exactly
what they have to do with the point which I was making which was about
how the halting problem is actually defined.
Mt axioms show that the Halting Problem was defined with
insufficient detail. When we add my detail thenn
(then and only then) we can see exactly where it went wrong
On 2026-10-14 08:12, olcott wrote:
On 10/14/2026 8:47 AM, André G. Isaak wrote:
Even if I were to accept your axioms, it's not clear to me exactly
what they have to do with the point which I was making which was
about how the halting problem is actually defined.
Mt axioms show that the Halting Problem was defined with
insufficient detail. When we add my detail thenn
(then and only then) we can see exactly where it went wrong
Which detail do you think is missing from the below?
Is it possible to construct a Turing Machine which computes the Halting Function, that is which rejects all computations which fail to halt and which accepts all computations which eventually halt.
That doesn't appear to be lacking any detail to me. It's a simply yes/no question very precisely posed. Your new axioms shed no light on this question whatsoever
André
On 10/14/2026 10:14 AM, André G. Isaak wrote:
On 2026-10-14 08:12, olcott wrote:
On 10/14/2026 8:47 AM, André G. Isaak wrote:
Even if I were to accept your axioms, it's not clear to me exactly
what they have to do with the point which I was making which was
about how the halting problem is actually defined.
Mt axioms show that the Halting Problem was defined with
insufficient detail. When we add my detail thenn
(then and only then) we can see exactly where it went wrong
Which detail do you think is missing from the below?
Is it possible to construct a Turing Machine which computes the
Halting Function, that is which rejects all computations which fail to
halt and which accepts all computations which eventually halt.
This incorrectly assumes that the halt decider is a math
function that has an executing process as its input.
A halt decider is a computation. It is not a math function.
No. Your concrete example does not prove the word "ONLY".
You show:
HHH cannot obtain the behavior of DD()
by its recursive simulation of DD.
Agreed.
You then assert:
therefore the ONLY way HHH could decide whether
DD() halts would be an incorrect transformation.
That does not follow.
Here is a concrete alternative decider.
Suppose H recognizes programs of the form:
int main() {
unsigned n = CONSTANT;
while (n > 0)
n--;
return 0;
}
H can inspect the syntax and prove:
n is initially finite;
every loop iteration strictly decreases n;
n cannot decrease below 0;
therefore the loop terminates;
therefore the program halts.
H returns HALTS.
H did not simulate CONSTANT iterations. For CONSTANT = 4000000000, it
does not generate four billion C execution states.
It established termination from a ranking function.
That is a semantically correct decision about the program's execution without reproducing that execution.--
So your counter-example establishes failure of one method:
recursive simulation.
It does not establish:
simulation is the ONLY semantically correct
method for deciding halting.
Static proofs of termination are concrete counterexamples to that claim.
Therefore the word "ONLY" in Generic Axiom 2 still requires proof.
Good. Then "simulation" is no longer the issue.
You accept that H may use any shortcut, proof, static analysis, etc., provided its conclusion respects the semantics of its finite-string input.
I agree completely.
So here is now the EXACT proposition your argument must prove:
For the finite C source string DD,
it is semantically correct for HHH to answer
NON-HALTING because of the recursive HHH(DD) relationship,
BUT
it would be semantically incorrect for HHH to answer
HALTING on the grounds that DD() returns when HHH(DD)
returns 0.
That is the logical target.
You cannot prove it merely by showing:
HHH's recursive analysis does not reach DD's
simulated final halt state.
We already agree about that.
You must prove the stronger statement:
The first behavior is the semantic property that
HHH is required to classify, while the second behavior
is NOT a semantic property HHH is permitted to classify.
THAT is where "ONLY" enters your argument.
And THAT is what your Axiom 2 has not established.--
Saying that considering DD() would "ignore the semantics" simply
restates the conclusion.
You must show why it ignores the semantics.
That is now the entire disagreement.
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.
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.
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
Le 22/10/2026 à 16:01, olcott a écrit :
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
Yes. I still agree with exactly what you quoted.
Correct application of the C operational semantics within HHH gives:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
So what, precisely, do you think follows from quoting this?
Because this establishes the recursive simulated execution.
It does not establish that HHH may replace that execution by some
different finite derivation and still claim to have determined what
DD does.
On 10/22/2026 9:03 AM, Python wrote:
Le 22/10/2026 à 16:01, olcott a écrit :
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
Yes. I still agree with exactly what you quoted.
Correct application of the C operational semantics within HHH gives:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
So what, precisely, do you think follows from quoting this?
Because this establishes the recursive simulated execution.
It does not establish that HHH may replace that execution by some
different finite derivation and still claim to have determined what
DD does.
It proves that your recent disagreement with these
same words was incorrect at the very least.
Le 22/10/2026 à 16:01, olcott a écrit :
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
Yes. I still agree with exactly what you quoted.
Correct application of the C operational semantics within HHH gives:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
So what, precisely, do you think follows from quoting this?
Because this establishes the recursive simulated execution.
It does not establish that HHH may replace that execution by some
different finite derivation and still claim to have determined what
DD does.
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
DO NOT ERASE A SINGLE CHARACTER OF THE WORDS THAT YOU
ARE RESPONDING TO, NOT EVEN A COMMA. LEAVE THEM QUOTED
EXACTLY AS THEY ARE.
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
DO NOT ERASE A SINGLE CHARACTER OF THE WORDS THAT YOU
ARE RESPONDING TO, NOT EVEN A COMMA. LEAVE THEM QUOTED
EXACTLY AS THEY ARE.
Excellent rule, Peter.
Now apply it yourself.
For once, have enough intellectual honesty to quote EXACTLY the words of mine that you claim to be refuting, without silently changing what they
say.
Here are my words, which you keep quoting:
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
NOT ONE CHARACTER of that says:
therefore DD does not halt.
Of course it does not say this.
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.
Establishes that the behavior of DD has never been any of
the damned business of HHH.
the behavior of DD has never been any of
the damned business of HHH.
It also establishes that
the DD input to the above HHH
[...]
cannot possibly reach its own line 06, thus does not halt.
Of course it does not say this.
Of course it does not say this.
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.
Establishes that the behavior of DD has never been any of
the damned business of HHH.
Peter, thank you.
Seriously.
After weeks of this, you have finally stated the entire problem yourself:
the behavior of DD has never been any of
the damned business of HHH.
Then HHH is not a halting decider for DD.
On 10/22/2026 11:20 AM, Python wrote:
Of course it does not say this.
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.
Establishes that the behavior of DD has never been any of
the damned business of HHH.
Peter, thank you.
Seriously.
After weeks of this, you have finally stated the entire problem yourself:
the behavior of DD has never been any of
the damned business of HHH.
Then HHH is not a halting decider for DD.
All deciders have only ever operated on finite
strings. It has always been a stupid mistake to
assume otherwise.
All deciders have only ever operated on finite
strings. It has always been a stupid mistake to
assume otherwise.
All deciders have only ever operated on finite
strings. It has always been a stupid mistake to
assume otherwise.
Nobody assumed otherwise, Peter.
Not once.
Of course HHH operates on a finite string encoding DD.
Now answer the question you just avoided.
What does:
HHH(DD) = 0
mean?
DD simulated by HHH according to the operational semantics
of the C programming language cannot possibly reach its own
simulated final state and halt.
DD simulated by HHH according to the operational semantics
of the C programming language cannot possibly reach its own
simulated final state and halt.
For fuck's sake, Peter.
That was NOT the question.
I asked:
What does HHH(DD) = 0 mean?
DD simulated by HHH according to the operational semantics
of the C programming language cannot possibly reach its own
simulated final state and halt.
For fuck's sake, Peter.
That was NOT the question.
I asked:
What does HHH(DD) = 0 mean?
Literally it means this.
Halt7.c(1378): error C2106: '=': left operand must be l-value
When we correct the compile time error:
What does HHH(DD) == 0 mean?
It derives its meaning ONLY by applying a sequence
of finite string transformations to its finite
string input.
--Literally it means this.
Halt7.c(1378): error C2106: '=': left operand must be l-value
When we correct the compile time error:
What does HHH(DD) == 0 mean?
Oh, for fuck's sake.
You know perfectly well that
HHH(DD) = 0
was mathematical notation for "HHH applied to DD returns 0", not a C assignment statement.
Pretending otherwise is not clever. It is just tedious.
Now, for the THIRD time:
WHAT DOES THE RETURN VALUE 0 ASSERT?
Your answer:
It derives its meaning ONLY by applying a sequence
of finite string transformations to its finite
string input.
does not answer that question either.
That describes HOW you claim the value is computed.
I asked WHAT THE VALUE MEANS.
These are different questions.
If I ask:
What does strcmp(a,b) == 0 mean?
"its value is derived by finite string transformations" is not an answer.
The answer is:
the strings compare equal.
Likewise, you have spent years claiming that HHH is a halting decider.
So:
HHH(DD) returns 0
must assert SOME proposition.
WHAT IS IT?
You have now evaded this embarrassingly simple question three times.
And please spare us another recital of your "Axiom 1".
I will grant it completely for the sake of argument:
ALL COMPUTATIONS OPERATE BY FINITE STRING
TRANSFORMATIONS ON FINITE STRINGS.
Fine.
Granted.
100%.
It changes absolutely nothing.
Now answer:
WHAT PROPOSITION DOES HHH RETURNING 0 ASSERT?
Does it assert:
DD does not halt
YES or NO?
If YES, then the behavior of DD is precisely what HHH is making a claim about, and your earlier statement that DD's behavior is none of HHH's "damned business" collapses.
If NO, then HHH is not deciding whether DD halts, and your claimed counterexample to the Halting Theorem collapses.
Repeating "finite strings" does not create a third possibility.
And confusing the METHOD by which a result is computed with the MEANING
of the result is becoming painfully boring.
So no more detours into C syntax.
No more Post.
No more "finite string transformations."
No more descriptions of the recursive simulation.
One question:
Does HHH returning 0 assert that DD does not halt?
YES or NO?
If after all these years you cannot state what the output of your own alleged halting decider means, there is nothing left to discuss.
Literally it means this.
Halt7.c(1378): error C2106: '=': left operand must be l-value
When we correct the compile time error:
What does HHH(DD) == 0 mean?
Oh, for fuck's sake.
You know perfectly well that
HHH(DD) = 0
was mathematical notation for "HHH applied to DD returns 0", not a C assignment statement.
Pretending otherwise is not clever. It is just tedious.
Now, for the THIRD time:
WHAT DOES THE RETURN VALUE 0 ASSERT?
Your answer:
It derives its meaning ONLY by applying a sequence
of finite string transformations to its finite
string input.
does not answer that question either.
That describes HOW you claim the value is computed.
I asked WHAT THE VALUE MEANS.
These are different questions.
If I ask:
What does strcmp(a,b) == 0 mean?
"its value is derived by finite string transformations" is not an answer.
The answer is:
the strings compare equal.
Likewise, you have spent years claiming that HHH is a halting decider.
So:
HHH(DD) returns 0
must assert SOME proposition.
WHAT IS IT?
You have now evaded this embarrassingly simple question three times.
And please spare us another recital of your "Axiom 1".
I will grant it completely for the sake of argument:
ALL COMPUTATIONS OPERATE BY FINITE STRING
TRANSFORMATIONS ON FINITE STRINGS.
Fine.
Granted.
100%.
It changes absolutely nothing.
Now answer:
WHAT PROPOSITION DOES HHH RETURNING 0 ASSERT?
Does it assert:
DD does not halt
YES or NO?
If YES, then the behavior of DD is precisely what HHH is making a claim about, and your earlier statement that DD's behavior is none of HHH's "damned business" collapses.
If NO, then HHH is not deciding whether DD halts, and your claimed counterexample to the Halting Theorem collapses.
Repeating "finite strings" does not create a third possibility.--
And confusing the METHOD by which a result is computed with the MEANING
of the result is becoming painfully boring.
So no more detours into C syntax.
No more Post.
No more "finite string transformations."
No more descriptions of the recursive simulation.
One question:
Does HHH returning 0 assert that DD does not halt?
YES or NO?
If after all these years you cannot state what the output of your own alleged halting decider means, there is nothing left to discuss.
EXPECTING HHH TO REPORT ON DD() IS THE MISTAKE
EXPECTING HHH TO REPORT ON DD() IS THE MISTAKE
Then HHH is not a halting decider.
That's it.
A halting decider is, by definition, a procedure whose output reports whether the computation represented by its input halts.
I don't care whether HHH is a mathematical function, a C program, a--
Turing machine, or a trained hamster manipulating finite strings.
If
HHH(DD) == 0
does not assert anything about whether
DD()
halts, then HHH does not decide whether DD halts.
If it does assert something about whether DD halts, then your statement
EXPECTING HHH TO REPORT ON DD() IS THE MISTAKE
is false.
There is still no third possibility.
a halt decider operates on a finite string of input source-code to determine whether or not this finite string of input source-code specifies a sequence of
steps that reach their own final state.
Excellent. Then you have finally answered my question.
I'll use YOUR definition, verbatim:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
Fine. I accept that definition completely.
Now let the finite input source-code be DD.
Then HHH must determine whether the finite source-code DD specifies a sequence of steps that reaches its final state.
That is precisely what I mean by asking whether DD() halts.
You have merely replaced--
"Does DD() halt?"
with
"Does the finite source-code DD specify a sequence of steps
that reaches its final state?"
Those are not two different questions. The second is your operational description of the first.
So now answer using your own terminology:
HHH(DD) == 0
asserts that the finite source-code DD specifies WHAT?
A) a sequence of steps that reaches its final state
or
B) a sequence of steps that does not reach its final state
A or B?
No mathematical functions.
No semantics terminology.
No interpretation of my axioms.
Just apply your own definition of "halt decider" to the finite source-
code DD.
That assumes the counterfactual that HHH1(DD) == HHH(DD)
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
That assumes the counterfactual that HHH1(DD) == HHH(DD)
Oh, wonderful.
And now, magically, HHH1 appears.
We have spent all this time discussing HHH.
I quote YOUR definition of a halt decider.
I give HHH the finite source-code DD.
I ask the spectacularly difficult question of what HHH's answer says
about that finite source-code.
And suddenly:
HHH1
Where the fuck did HHH1 come from?
I did not mention HHH1.--
My question does not mention HHH1.
Your definition of a halt decider does not require HHH1.
Nothing I wrote assumes:
HHH1(DD) == HHH(DD)
because NOTHING I wrote contains HHH1 at all.
This is getting ridiculous.
YOUR definition was:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
Fine.
The finite string is DD.
The halt decider is HHH.
So, according to YOUR OWN DEFINITION, HHH must determine whether DD specifies:
A) a sequence of steps that reaches its final state
or
B) a sequence of steps that does not reach its final state.
That is it.
There is no HHH1 in that question.
There is no "counterfactual".
There is no appeal to conventional terminology.
There is no mathematical-function trick.
There is not even any disagreement about finite strings left for you to
hide behind.
I have adopted YOUR terminology, YOUR definition, and YOUR finite-string formulation.
And you STILL refuse to answer A or B.
The pattern is becoming almost comical:
When asked what HHH(DD) = 0 means:
"finite strings!"
When that escape is closed:
"operational semantics!"
When that escape is closed:
"Emil Post!"
When I grant your Post axiom:
"You wrote = instead of ==!"
When I use your own definition verbatim and ask A or B:
"HHH1!"
At this rate I assume HHH2, HHH3 and HHH4 are waiting backstage.
Peter, this is six lines of C, not an expanding cinematic universe.
Forget HHH1.
We are discussing HHH.
By YOUR definition, HHH is supposed to determine whether its finite source-code input specifies a sequence of steps reaching its final state.
Its input is DD.
HHH returns 0.
Therefore, according to YOUR definition of HHH, which of these does 0 report?
A) DD specifies a sequence of steps that reaches its final state.
B) DD specifies a sequence of steps that does not reach its final state.
A or B?
If you answer B, we can examine whether that answer is correct.
If you answer A, we can examine whether that answer is correct.
If you introduce HHH1, Post, finite strings, C syntax, simulations, counterfactuals, or another newly invented detour instead of answering A
or B, you will merely demonstrate yet again that you are unwilling to
state what the output of your own alleged halt decider actually reports.
A.
Or.
B.
As I already said HHH1 is identical to HHH except that
DD never calls HHH1.
DD simulated by HHH1 has identical behavior to DD()
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
DD simulated by HHH1 has identical behavior to DD()
As I already said HHH1 is identical to HHH except that
DD never calls HHH1.
DD simulated by HHH1 has identical behavior to DD()
Wonderful.
And completely irrelevant to the question.
You have now explained what HHH1 is.
I did not ask what HHH1 is.
I asked what HHH reports about DD.
You deleted approximately fifty lines of my message while somehow--
preserving the one escape hatch you wanted to crawl through.
So here it is again, reduced to a size that should make evasion
genuinely difficult.
YOUR definition:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
Input:
DD
Decider:
HHH
Result:
0
According to YOUR definition, does that 0 report:
A) DD specifies a sequence of steps that reaches its final state.
or:
B) DD specifies a sequence of steps that does not reach its final state.
A or B?
HHH1 is not one of the choices.
And, incidentally, your description of HHH1 makes the irony rather spectacular.
You say:
DD simulated by HHH1 has identical behavior to DD()
Excellent.
So you yourself recognize that what happens when DD is executed depends
on what the HHH call inside DD actually does.
With HHH1, you say DD behaves like DD().
With HHH, you produce the recursive simulation:
HHH -> DD -> HHH -> DD -> ...
So congratulations: you have just rediscovered why replacing one
execution context with another does not magically establish what the original computation does.
But we don't even need to go there yet.
I am still waiting for the answer you have now repeatedly refused to give.
HHH(DD) returns 0.
Under YOUR definition of "halt decider", what does that report about the finite source-code DD?
A or B?
Not HHH1.
Not another simulator.
Not Post.
Not "finite strings".
Not a description of how you obtained the answer.
The answer itself.
A.
Or.
B.
This is becoming less like a disagreement about computability and more
like watching someone desperately avoid ticking one of two boxes.
I keep telling you that asking any decider about
the behavior of any external process is like
asking for the square-root of a dead chicken.
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
You know that deciders only operate on finite strings
and even though you "know" this you keep insisting
that they operate on external processes that are
not finite strings.
I keep telling you that asking any decider about
the behavior of any external process is like
asking for the square-root of a dead chicken.
Peter, this is getting fucking absurd.
I DID NOT ASK HHH ABOUT AN EXTERNAL PROCESS.
int main()
{
DD(); // this is the behavior that you are asking about
}
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
this is the behavior that you are asking about
int main()
{
DD(); // this is the behavior that you are asking about
}
NO, Peter.
For fuck's sake.
NO.
That is NOT the question I asked.
I explicitly removed `main()`, precisely because you kept whining about "external processes."
Here is the question AGAIN, in YOUR OWN WORDS:--
Finite input string: DD
Does that finite string specify a sequence
of steps reaching its final state?
That is not my definition.
That is YOUR definition of what a halt decider determines:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
There is no `main()` in my question.
YOU just inserted it.
There is no external process in my question.
YOU just inserted one.
I am asking about the finite source-code string DD and whether, in YOUR terminology, it "specifies a sequence of steps that reach their own
final state."
And instead of answering, you write:
int main()
{
DD();
}
and announce:
this is the behavior that you are asking about
NO.
IT.
ISN'T.
You no longer even have the excuse that I am imposing conventional terminology on you.
I am quoting YOUR DEFINITION VERBATIM.
So let's make this almost insultingly simple.
According to you:
A halt decider determines whether its finite
source-code input specifies a sequence of steps
reaching its final state.
Correct?
HHH is a halt decider.
Correct?
DD is its finite source-code input.
Correct?
HHH returns 0.
Correct?
Then what does 0 report?
A) The finite source-code DD specifies a sequence
of steps reaching its final state.
B) The finite source-code DD specifies a sequence
of steps not reaching its final state.
A or B?
Do not show me `main()` again.
Do not tell me what question you would prefer me to be asking.
Do not invent an external process and then accuse me of asking about it.
READ THE FUCKING QUESTION.
A.
Or.
B.
int main()
{
DD(); // this is the behavior that you are asking about
}
NO, Peter.
For fuck's sake.
NO.
That is NOT the question I asked.
I explicitly removed `main()`, precisely because you kept whining about "external processes."
Here is the question AGAIN, in YOUR OWN WORDS:
Finite input string: DD
Does that finite string specify a sequence
of steps reaching its final state?
That is not my definition.
That is YOUR definition of what a halt decider determines:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
There is no `main()` in my question.
YOU just inserted it.
There is no external process in my question.
YOU just inserted one.
I am asking about the finite source-code string DD and whether, in YOUR terminology, it "specifies a sequence of steps that reach their own
final state."
And instead of answering, you write:
int main()
{
DD();
}
and announce:
this is the behavior that you are asking about
NO.
IT.
ISN'T.
You no longer even have the excuse that I am imposing conventional terminology on you.
I am quoting YOUR DEFINITION VERBATIM.
So let's make this almost insultingly simple.
According to you:
A halt decider determines whether its finite
source-code input specifies a sequence of steps
reaching its final state.
Correct?
HHH is a halt decider.
Correct?
DD is its finite source-code input.
Correct?
HHH returns 0.
Correct?
Then what does 0 report?
A) The finite source-code DD specifies a sequence
of steps reaching its final state.
B) The finite source-code DD specifies a sequence
of steps not reaching its final state.
A or B?
Do not show me `main()` again.
Do not tell me what question you would prefer me to be asking.
Do not invent an external process and then accuse me of asking about it.
READ THE FUCKING QUESTION.
A.
Or.
B.
On 3/16/2025 2:18 PM, dbush wrote:
That doesn't change the fact that I want to know if any arbitrary
algorithm X with input Y will halt when executed directly.
That is a stupid and arbitrary requirement
You can't reason with someone who doesn't even understand what the
halting problem is about.
On 3/16/2025 3:54 PM, olcott wrote:
That is a stupid and arbitrary requirement
The Halting Theorem HAS ALWAYS ASKED ABOUT
THE BEHAVIOR OF AN EXTERNAL PROCESS.
THAT HAS ALWAYS BEEN ITS KEY MISTAKE.
That is a stupid and arbitrary requirement
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
The Halting Theorem HAS ALWAYS ASKED ABOUT
THE BEHAVIOR OF AN EXTERNAL PROCESS.
THAT HAS ALWAYS BEEN ITS KEY MISTAKE.
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
THE BEHAVIOR OF AN EXTERNAL PROCESS
when HHH is asked about the behavior
of DD it is asked about the DD() executed
from main().
On 10/22/2026 8:47 PM, Python wrote:
int main()
{
DD(); // this is the behavior that you are asking about
}
NO, Peter.
For fuck's sake.
NO.
That is NOT the question I asked.
I explicitly removed `main()`, precisely because you kept whining
about "external processes."
Here is the question AGAIN, in YOUR OWN WORDS:
Finite input string: DD
Does that finite string specify a sequence
of steps reaching its final state?
That is not my definition.
That is YOUR definition of what a halt decider determines:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
There is no `main()` in my question.
YOU just inserted it.
There is no external process in my question.
YOU just inserted one.
I am asking about the finite source-code string DD and whether, in
YOUR terminology, it "specifies a sequence of steps that reach their
own final state."
And instead of answering, you write:
int main()
{
DD();
}
and announce:
this is the behavior that you are asking about
NO.
IT.
ISN'T.
You no longer even have the excuse that I am imposing conventional
terminology on you.
I am quoting YOUR DEFINITION VERBATIM.
So let's make this almost insultingly simple.
According to you:
A halt decider determines whether its finite
source-code input specifies a sequence of steps
reaching its final state.
Correct?
HHH is a halt decider.
Correct?
DD is its finite source-code input.
Correct?
HHH returns 0.
Correct?
Then what does 0 report?
A) The finite source-code DD specifies a sequence
of steps reaching its final state.
B) The finite source-code DD specifies a sequence
of steps not reaching its final state.
A or B?
Do not show me `main()` again.
Do not tell me what question you would prefer me to be asking.
Do not invent an external process and then accuse me of asking about it.
READ THE FUCKING QUESTION.
A.
Or.
B.
You can't reason with someone who doesn't even understand what the
halting problem is about.
On 3/16/2025 3:54 PM, olcott wrote:
On 3/16/2025 2:18 PM, dbush wrote:
That doesn't change the fact that I want to know if any arbitrary
algorithm X with input Y will halt when executed directly.
That is a stupid and arbitrary requirement
The Halting Theorem HAS ALWAYS ASKED ABOUT
THE BEHAVIOR OF AN EXTERNAL PROCESS.
THAT HAS ALWAYS BEEN ITS KEY MISTAKE.
No, Peter.
And after all these months, you have finally stated YOUR key mistake
with extraordinary clarity.
The Halting Theorem does NOT require the decider to "operate on an
external process."
The decider operates on a FINITE DESCRIPTION OF A COMPUTATION.
Everyone agrees about that.
You agree about that.
I agree about that.--
Turing, Post, and every conventional formulation of computability agree about that.
The question is whether THE COMPUTATION DESCRIBED BY THAT FINITE INPUT reaches its final state.
And astonishingly, that is exactly how YOU defined a halt decider:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
READ YOUR OWN FUCKING WORDS:
"whether or not this finite string ...
SPECIFIES a sequence of steps..."
The decider operates on the finite string.
The finite string specifies a computation.
The decider determines a property of the computation specified by that string.
There is no requirement whatsoever that the decider physically operate
on some "external process."
That bizarre requirement exists only in your head.
This distinction is so elementary that we use it everywhere in computer science.
A compiler receives a finite string representing a program.
A static analyzer receives a finite string representing a program.
A model checker receives a finite representation of a system.
None of them needs to confuse the representation with the thing
represented.
And neither does a hypothetical halt decider.
So when you scream:
THE BEHAVIOR OF AN EXTERNAL PROCESS
you are attacking something the theorem never required.
And then you write:
when HHH is asked about the behavior
of DD it is asked about the DD() executed
from main().
No.
You are STILL trying to insert `main()` into a question from which I explicitly removed it.
I even used YOUR OWN formulation precisely to prevent this bullshit.
Here it is AGAIN:
finite input source-code: DD
Question:
Does this finite source-code specify a sequence
of steps that reaches its final state?
That is YOUR definition.
Not mine.
There is no external process in that question.
There is no `main()` in that question.
There is a finite string and a property of the computation specified by
that finite string.
Which brings us straight back to the question you are desperately
refusing to answer:
HHH receives the finite source-code DD.
HHH returns 0.
According to YOUR OWN definition of a halt decider, does that report:
A) DD specifies a sequence of steps that reaches
its final state.
or:
B) DD specifies a sequence of steps that does not
reach its final state.
A or B?
And notice how spectacularly your position collapses if you refuse
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
You agree about that.
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
I am stopping here until you pay
enormously much more attention.
operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
I am stopping here until you pay
enormously much more attention.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
You agree about that.
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
I am stopping here until you pay
enormously much more attention.
Fine.
Then I withdraw the expression:
"finite description of a computation"
entirely.
Gone.
You don't like it. I don't need it.
Now perhaps you can stop screaming long enough to pay "enormously much
more attention" to YOUR OWN WORDS.
You defined a halt decider as something that:
operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
Those are YOUR words.
I will use ONLY those words.
No "description of a computation."
No "external process."
No `main()`.
No terminology from the conventional Halting Theorem.
No terminology from me at all.
Just Olcott.
Here we go.
HHH operates on:
a finite string of input source-code
That finite string is:
DD
According to YOUR definition, HHH determines whether that finite string:
specifies a sequence of steps that reach their own final state
HHH returns:
0
So what does that 0 determine?
A) The finite string of input source-code DD
specifies a sequence of steps that reaches
its final state.
or:
B) The finite string of input source-code DD
specifies a sequence of steps that does NOT
reach its final state.
A or B?
That's it.
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
You can call "finite description of a computation" a misnomer five times.
You can disagree with it in capital letters four times.
Fine.
I HAVE NOW REMOVED IT.
Nothing changes.
The question survives entirely in YOUR vocabulary.
And the irony of this:
I am stopping here until you pay
enormously much more attention.
is becoming magnificent.
Peter, I have been paying so much attention that I have progressively removed EVERY SINGLE TERM you objected to.
You objected to "behavior."
Removed.
You objected to "external process."
Removed.
You objected to `DD()` from `main()`.
Removed.
You objected to conventional halting terminology.
Removed.
You demanded finite strings.
Granted.
You demanded operational terminology.
Granted.
You supplied your own definition.
Accepted VERBATIM.
Now you object to "finite description of a computation."
Fine.
REMOVED.
And after all of that, the same fucking question is still sitting there untouched:
Does HHH's 0 determine that the finite source-code DD
specifies a sequence of steps that reaches its final state,
or that it does not?
A or B?
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
You have now spent vastly more characters explaining why you will not
answer this question than would have been required to answer it.
One character, Peter.--
A
or:
B
And if you "stop here" rather than type that one character, after I have reformulated the question entirely in YOUR OWN WORDS, I think everyone reading this thread can draw the appropriate conclusion.
Take all the time you need.
On 10/22/2026 8:28 PM, Python wrote:
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
That in itself has always been a misnomer.
You agree about that.
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
HELL NO I DISAGREED MANY TIMES
I am stopping here until you pay
enormously much more attention.
Fine.
Then I withdraw the expression:
"finite description of a computation"
entirely.
Gone.
You don't like it. I don't need it.
Now perhaps you can stop screaming long enough to pay "enormously much
more attention" to YOUR OWN WORDS.
You defined a halt decider as something that:
operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
Those are YOUR words.
I will use ONLY those words.
No "description of a computation."
No "external process."
No `main()`.
No terminology from the conventional Halting Theorem.
No terminology from me at all.
Just Olcott.
Here we go.
HHH operates on:
a finite string of input source-code
That finite string is:
DD
According to YOUR definition, HHH determines whether that finite string:
specifies a sequence of steps that reach their own final state
HHH returns:
0
So what does that 0 determine?
A) The finite string of input source-code DD
specifies a sequence of steps that reaches
its final state.
or:
B) The finite string of input source-code DD
specifies a sequence of steps that does NOT
reach its final state.
A or B?
That's it.
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
You can call "finite description of a computation" a misnomer five times.
You can disagree with it in capital letters four times.
Fine.
I HAVE NOW REMOVED IT.
Nothing changes.
The question survives entirely in YOUR vocabulary.
And the irony of this:
I am stopping here until you pay
enormously much more attention.
is becoming magnificent.
Heh, you did pay enormously better attention.
Peter, I have been paying so much attention that I have progressively
removed EVERY SINGLE TERM you objected to.
You objected to "behavior."
Removed.
You objected to "external process."
Removed.
You objected to `DD()` from `main()`.
Removed.
You objected to conventional halting terminology.
Removed.
You demanded finite strings.
Granted.
You demanded operational terminology.
Granted.
You supplied your own definition.
Accepted VERBATIM.
Now you object to "finite description of a computation."
Fine.
REMOVED.
And after all of that, the same fucking question is still sitting
there untouched:
Does HHH's 0 determine that the finite source-code DD
specifies a sequence of steps that reaches its final state,
or that it does not?
A or B?
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
You already answered this.
You have now spent vastly more characters explaining why you will not
answer this question than would have been required to answer it.
You and others have mere false assumptions hardwired
into your brains as if they were immutable truisms.
One character, Peter.
A
or:
B
And if you "stop here" rather than type that one character, after I
have reformulated the question entirely in YOUR OWN WORDS, I think
everyone reading this thread can draw the appropriate conclusion.
Take all the time you need.
Does HHH's 0 determine that the finite source-code DD
specifies a sequence of steps that reaches its final state,
or that it does not?
A or B?
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
You have now spent vastly more characters explaining why you will not--
answer this question than would have been required to answer it.
One character, Peter.
A
or:
B
And if you "stop here" rather than type that one character, after I have reformulated the question entirely in YOUR OWN WORDS, I think everyone reading this thread can draw the appropriate conclusion.
Take all the time you need.
Nobody seems to like this one, pseudo code:That assumes the counterfactual that HHH1(DD) == HHH(DD)
Oh, wonderful.
And now, magically, HHH1 appears.
We have spent all this time discussing HHH.
I quote YOUR definition of a halt decider.
I give HHH the finite source-code DD.
I ask the spectacularly difficult question of what HHH's answer says
about that finite source-code.
And suddenly:
HHH1
Where the fuck did HHH1 come from?
I did not mention HHH1.
My question does not mention HHH1.
Your definition of a halt decider does not require HHH1.
Nothing I wrote assumes:
HHH1(DD) == HHH(DD)
because NOTHING I wrote contains HHH1 at all.
This is getting ridiculous.
YOUR definition was:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
Fine.
The finite string is DD.
The halt decider is HHH.
So, according to YOUR OWN DEFINITION, HHH must determine whether DD specifies:
A) a sequence of steps that reaches its final state
or
B) a sequence of steps that does not reach its final state.
That is it.
There is no HHH1 in that question.
There is no "counterfactual".
There is no appeal to conventional terminology.
There is no mathematical-function trick.
There is not even any disagreement about finite strings left for you to
hide behind.
I have adopted YOUR terminology, YOUR definition, and YOUR finite-string formulation.
And you STILL refuse to answer A or B.
The pattern is becoming almost comical:
When asked what HHH(DD) = 0 means:
"finite strings!"
When that escape is closed:
"operational semantics!"
When that escape is closed:
"Emil Post!"
When I grant your Post axiom:
"You wrote = instead of ==!"
When I use your own definition verbatim and ask A or B:
"HHH1!"
At this rate I assume HHH2, HHH3 and HHH4 are waiting backstage.
Peter, this is six lines of C, not an expanding cinematic universe.
Forget HHH1.
We are discussing HHH.
By YOUR definition, HHH is supposed to determine whether its finite source-code input specifies a sequence of steps reaching its final state.
Its input is DD.
HHH returns 0.
Therefore, according to YOUR definition of HHH, which of these does 0 report?
A) DD specifies a sequence of steps that reaches its final state.
B) DD specifies a sequence of steps that does not reach its final state.
A or B?
If you answer B, we can examine whether that answer is correct.
If you answer A, we can examine whether that answer is correct.
If you introduce HHH1, Post, finite strings, C syntax, simulations, counterfactuals, or another newly invented detour instead of answering A
or B, you will merely demonstrate yet again that you are unwilling to
state what the output of your own alleged halt decider actually reports.
A.
Or.
B.
*keeps repeating unless aborted*
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()
*Simulation invariant*
DD correctly simulated by HHH cannot possibly reach its
simulated final state.
Your own answer to A or B:
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
keeps repeating unless aborted
correct application of the C operational
semantics within HHH produces the recursively simulated sequence
Of course it does not say this.
*keeps repeating unless aborted*
Line 03: simulated DD() invokes simulated HHH(DD) that simulates DD()
*Simulation invariant*
DD correctly simulated by HHH cannot possibly reach its
simulated final state.
Your own answer to A or B:
On 10/9/2026 6:53 AM, Python wrote:
You have established that correct application of the C operational
semantics within HHH produces the recursively simulated sequence:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Agreed.
Peter, I understand perfectly well what I agreed to.
I agreed that IF HHH keeps recursively simulating the HHH call
encountered at DD line 03, then we obtain:
HHH -> DD -> HHH -> DD -> ...
and that recursive simulation does not naturally return.
I have agreed to that approximately seventeen fucking times now.
What I did NOT agree to is your next inference:
therefore the finite source-code DD specifies
a computation that does not halt.
Those are not the same proposition.
And your own words expose the exact problem:
keeps repeating unless aborted
UNLESS ABORTED.
There it is.
That is the entire fucking issue.
You claim that HHH detects this recursion, ABORTS the simulation, and returns 0.
Fine.
Then tell me what happens to the HHH call at line 03 of the DD being simulated.
There are only two possibilities.--
FIRST:
The simulated call
HHH(DD)
at DD line 03 returns the 0 that you claim HHH returns.
Then the C operational semantics are embarrassingly simple:
03 int Halt_Status = HHH(DD);
gives:
Halt_Status = 0
then:
04 if (Halt_Status)
is false, so line 05 is skipped, and:
06 return Halt_Status;
is reached.
DD HALTS.
SECOND:
The simulated call to HHH at line 03 does NOT return 0 because you
continue recursively simulating:
HHH -> DD -> HHH -> DD -> ...
Fine.
Then your simulation never produces the alleged 0 for that call.
In that case you have not shown that HHH returns 0 there.
You have shown that YOUR METHOD FOR COMPUTING HHH'S ANSWER DOES NOT TERMINATE.
That is the dilemma you have been running away from for weeks.
And no, my October 9 statement does not answer it for you.
Read it:
correct application of the C operational
semantics within HHH produces the recursively simulated sequence
Yes.
THE RECURSIVELY SIMULATED SEQUENCE.
I agreed about the behavior of your recursive simulation.
I did NOT say:
therefore DD does not halt.
In fact, a few days ago when I explicitly pointed this out, you answered:
Of course it does not say this.
Remember?
So please stop pretending that my October 9 statement contains words
that YOU HAVE ALREADY ADMITTED IT DOES NOT CONTAIN.
Your latest post actually makes the defect beautifully explicit:
"keeps repeating unless aborted"
If it is NOT aborted:
HHH does not finish deciding DD.
If it IS aborted and 0 is returned to the simulated DD:
DD reaches line 06 and halts.
Pick your poison.
You do not get a magical third option in which:
HHH aborts and returns 0
but simultaneously:
the DD waiting for that return at line 03
never receives the 0
while you still call the whole thing a correct simulation according to
the C operational semantics.
That is not C semantics.
That is sleight of hand.
You are using the non-return of HHH to prove that DD cannot get past
line 03, while simultaneously using the return of HHH to claim that HHH
is a terminating decider.
You need HHH NOT TO RETURN to prove your conclusion about DD.
You need HHH TO RETURN to call HHH a decider.
You cannot have both.
And THAT -- not some "mental block" of mine -- is the contradiction you
keep hiding behind the word "aborted."
Then why did you insist that it must return?
That is what is entailed by "does not naturally return."
Do you understand what "entailed by" means?
(a) There is a cat on my couch
(b) The couch is in my house
(c) Therefore the is a cat in my house.
Then tell me what happens to the HHH call at line 03 of the DD being simulated.
It ceases to exist.
It was only temporary data within HHH.
DD correctly simulated by HHH cannot possibly reach its
simulated final state.
It ceases to exist.
It was only temporary data within HHH.
Then why did you insist that it must return?
I didn't.
For approximately the eighteenth fucking time:
I said that YOU need HHH to return if you want HHH to be a terminating
halt decider.
I completely agree that if you recursively follow:
HHH -> DD -> HHH -> DD -> HHH -> ...
forever, it does not return.
That is precisely your problem, not mine.
Then you write:
That is what is entailed by "does not naturally return."
Do you understand what "entailed by" means?
Yes, Peter.
Unfortunately, you don't.
Your analogy:
(a) There is a cat on my couch
(b) The couch is in my house
(c) Therefore the is a cat in my house.
is a valid entailment.
Yours is not.
Your actual argument is:
(a) HHH's recursive simulation of DD does not return.
therefore:
(b) DD does not return.
That simply does not follow.
And your next answer finally exposes EXACTLY why.
I asked:
Then tell me what happens to the HHH call at line 03 of the DD being
simulated.
You answered:
It ceases to exist.
It was only temporary data within HHH.
THANK YOU.
There it is.
At last.
The simulated HHH call at line 03 DOES NOT RETURN 0.
It "ceases to exist."
The simulated DD waiting for that return DOES NOT receive 0.
Its simulated execution is simply discarded.
So you have NOT completed the simulation of DD according to the C operational semantics.
You have ABORTED it.--
That distinction could hardly be more elementary.
In C, evaluating:
int Halt_Status = HHH(DD);
does not have the following magical third outcome:
HHH does not return,
but DD's activation record "ceases to exist",
therefore DD has been proved not to halt.
If HHH returns, evaluation continues with the returned value.
If HHH does not return, evaluation does not continue.
If some OUTER program throws away the entire simulated machine state,
then the simulation has been ABORTED.
Throwing away a simulation state is not a transition of the program
being simulated.
Read that sentence again.
THROWING AWAY A SIMULATION STATE
IS NOT A TRANSITION OF THE PROGRAM
BEING SIMULATED.
And therefore:
DD correctly simulated by HHH cannot possibly reach its
simulated final state.
is now revealed as sleight of hand.
Of course it cannot reach its simulated final state AFTER YOU DELETE THE FUCKING SIMULATION.
Neither can a simulated `return 42;` reach its final state if I pull the plug on the simulator one instruction before `return`.
That does not prove that `return 42;` doesn't halt.
It proves that I stopped simulating it.
And now look at your own description:
HHH directly executes.
HHH creates temporary simulation data representing DD.
The simulated DD reaches line 03.
That creates further temporary simulation data.
Recursion is detected.
HHH aborts/discards that simulation data.
"It ceases to exist."
The outer HHH returns 0.
Fine.
What has been established?
That HHH's chosen simulation procedure encountered recursive simulation
and aborted it.
What has NOT been established?
That DD specifies a sequence of steps that fails to reach its final state.
Because you never completed that determination.
You destroyed the state from which the question had to be answered.
And this also destroys your alleged "entailment."
Your cat analogy would actually need to look something like this:
(a) I am searching my house for the cat.
(b) My search keeps recursively sending me back
to rooms I have already searched.
(c) I abort the search and throw away my search state.
(d) Therefore there is no cat in the house.
No, Peter.
(c) does not entail (d).
Your search procedure failing to terminate does not establish the
property it was supposed to decide.
And this is now particularly devastating because YOU supplied the
missing fact:
It ceases to exist.
It was only temporary data within HHH.
Exactly.
THE SIMULATION ceases to exist.
DD has not reached a simulated non-halting final verdict.
HHH has simply stopped simulating it.
So the situation is now even simpler than before:
If HHH keeps correctly simulating:
HHH -> DD -> HHH -> DD -> ...
and HHH never returns.
If HHH aborts:
the simulated DD "ceases to exist",
so HHH has stopped following DD's C execution.
You cannot turn the second case into proof of the first case's conclusion.
"ABORT SIMULATION" is not a new instruction in DD.
And deleting DD's simulated state is not evidence that DD doesn't halt.
It is evidence that your alleged decider gave up.
Yes you did. I am not going to bother to look it up.
It is the basis for HHH(DD)==0
It ceases to exist.
It was only temporary data within HHH.
I also "do not complete" any infinite loops.
The infinite loop behavior pattern catches this
and provides the abort and return 0 criteria.
Since you already admitted that DD correctly
simulated by HHH cannot possibly reach its own
simulated final halt state, you have admitted
that HHH(DD)==0 is correct.
Yes you did. I am not going to bother to look it up.
Bullshit.
You accuse me of having said something, and in the very next sentence announce that you cannot be bothered to produce the quote.
Either quote me saying that the recursive simulated HHH call MUST
return, or withdraw the accusation.
"I remember you saying it but I won't look it up" is not evidence.
Especially after I have told you, over and over again, exactly what I actually said:
If HHH recursively simulates forever, it does not return.
If HHH is a terminating halt decider, HHH itself must return an answer.
Those are not contradictory statements.
Then you write:
It is the basis for HHH(DD)==0
EXACTLY.
And that is the problem you keep dodging.
Your basis for RETURNING 0 is that the recursive simulation DOES NOT
RETURN.
Read that carefully.
You observe:
recursive simulation:
HHH -> DD -> HHH -> DD -> ...
does not return
and use that observation as:
basis for HHH(DD) returning 0.
Fine.
But DD CONTAINS THE CALL HHH(DD).
So once you claim that HHH(DD) actually returns 0, the C execution of DD
is:
Halt_Status = 0;
if (0)
goto HERE;
return 0;
DD halts.
Your response to this is not a rebuttal.
It is:
It ceases to exist.
It was only temporary data within HHH.
Yes.
BECAUSE YOU ABORTED THE SIMULATION.
And now:
I also "do not complete" any infinite loops.
The infinite loop behavior pattern catches this
and provides the abort and return 0 criteria.
You are simply repeating the assertion whose correctness is under dispute.
For an ordinary loop such as:
while (1) {}
recognizing a repeating machine state can indeed establish
nontermination under appropriate deterministic conditions.
But DD is exactly the adversarial case where your alleged decider's OWN RETURN VALUE participates in the computation being classified.
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
That is the entire fucking point.--
You cannot reason:
"My simulation shows that HHH never returns,
therefore I return 0,
therefore my simulation showing that HHH never
returns was correct."
The moment HHH returns 0, you have changed the premise on which your simulated DD was stuck at line 03.
And your answer to that remains:
"the simulated DD ceases to exist."
That is not a rebuttal.
That is literally an admission that you threw away the simulation before allowing it to observe the return value you claim HHH produces.
Then comes the most dishonest substitution in your post:
Since you already admitted that DD correctly
simulated by HHH cannot possibly reach its own
simulated final halt state, you have admitted
that HHH(DD)==0 is correct.
NO.
I admitted:
the recursively nested simulation
HHH -> DD -> HHH -> DD -> ...
does not naturally return.
I did NOT admit:
therefore HHH(DD)==0 correctly reports
that DD does not halt.
You know this distinction because I have stated it explicitly again and again.
More importantly, when I previously pointed out that my quoted October 9 words did NOT say "therefore DD does not halt", YOU ANSWERED:
"Of course it does not say this."
So stop putting the conclusion back into my mouth.
You have already admitted that it is not contained in the statement you
keep quoting.
Your argument still has the same fatal hole:
1. Simulate DD.
2. DD calls HHH.
3. Simulating that HHH recursively reproduces the pattern.
4. The recursive simulation therefore does not return.
5. ABORT IT.
6. Return 0.
7. Claim that step 4 proves DD does not halt.
No.
Step 5 destroyed the simulation.
Step 6 gives HHH the very return value that DD was waiting for at line 03.
If that return is delivered to DD, DD reaches line 06.
If it is not delivered to DD because DD "ceases to exist", then you did
not continue the simulation according to the C semantics.
There is no third possibility hiding inside the phrase "behavior pattern."
So please stop doing these three things:
claiming I said things while refusing to quote them;
replacing "the recursive simulation does not return"
with "DD does not halt";
and repeating your conclusion instead of answering
the objection to the inference that supposedly proves it.
You have not rebutted the objection.
You have simply ignored it and announced the disputed conclusion again.
And after this many repetitions, "you don't understand" is no longer an argument.
It is what you say instead of providing one.
You yourself show that none of the above HHH(DD)
returns and then expect me to see that it does return.
When you contradict yourself you prove that you
are incorrect.
none of the above HHH(DD) returns
It is the basis for HHH(DD)==0
THAT HAS ALWAYS BEEN THE FUNDAMENTAL FALSE ASSUMPTION.
none of the above HHH(DD) returns
But DD is exactly the adversarial case where your alleged decider's OWN RETURN VALUE participates in the computation being classified.
HHH simulates DD--
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
On 2026-10-23 07:21, olcott wrote:
Dunning/Kruger
My irony meter just exploded.
André
On 10/23/2026 11:15 AM, André G. Isaak wrote:
On 2026-10-23 07:21, olcott wrote:
Dunning/Kruger
My irony meter just exploded.
André
I know that I know that I am on the correct
side of that because I can finally explain
the key details that everyone else never noticed.
When we abandon the misleading terms:
(a) "Turing machine description" and replace it with
[Finite string source code for a Turing Machine]
(b) "Decider" and replace it with sequence of inference
steps that are applied to an input static finite string
that are syntactically or semantically relevant to the
decision criteria.
Concrete example of a decider where relevance is required.
int strcmp(const char *str1, const char *str2);
and the finite string inputs are the entire basis.
WE HAVE CORRECTED THE ERRORS AT THE FOUNDATION OF COMPUTATION.
At this point we only need to see what is semantically entailed
by these corrections.
On 2026-10-23 10:57, olcott wrote:
On 10/23/2026 11:15 AM, André G. Isaak wrote:
On 2026-10-23 07:21, olcott wrote:
Dunning/Kruger
My irony meter just exploded.
André
I know that I know that I am on the correct
side of that because I can finally explain
the key details that everyone else never noticed.
When we abandon the misleading terms:
(a) "Turing machine description" and replace it with
[Finite string source code for a Turing Machine]
(b) "Decider" and replace it with sequence of inference
steps that are applied to an input static finite string
that are syntactically or semantically relevant to the
decision criteria.
There's absolutely nothing misleading about either of the above terms.
The only reason you find them confusing is because you've never bothered
to learn the precise technical meanings of those terms and instead
interpret them in some incredibly vague way and then conclude you have
made some brilliant insight. That's classic Dunning-Kruger.
Concrete example of a decider where relevance is required.
int strcmp(const char *str1, const char *str2);
and the finite string inputs are the entire basis.
WE HAVE CORRECTED THE ERRORS AT THE FOUNDATION OF COMPUTATION.
At this point we only need to see what is semantically entailed
by these corrections.
You don't *understand* the foundations of computation and thus are in no position to 'correct' them.
André
On 2026-10-23 10:57, olcott wrote:
On 10/23/2026 11:15 AM, André G. Isaak wrote:
On 2026-10-23 07:21, olcott wrote:
Dunning/Kruger
My irony meter just exploded.
André
I know that I know that I am on the correct
side of that because I can finally explain
the key details that everyone else never noticed.
When we abandon the misleading terms:
(a) "Turing machine description" and replace it with
[Finite string source code for a Turing Machine]
(b) "Decider" and replace it with sequence of inference
steps that are applied to an input static finite string
that are syntactically or semantically relevant to the
decision criteria.
There's absolutely nothing misleading about either of the above terms.
The only reason you find them confusing is because you've never bothered
to learn the precise technical meanings of those terms and instead
interpret them in some incredibly vague way and then conclude you have
made some brilliant insight. That's classic Dunning-Kruger.
Concrete example of a decider where relevance is required.
int strcmp(const char *str1, const char *str2);
and the finite string inputs are the entire basis.
WE HAVE CORRECTED THE ERRORS AT THE FOUNDATION OF COMPUTATION.
At this point we only need to see what is semantically entailed
by these corrections.
You don't *understand* the foundations of computation and thus are in no position to 'correct' them.
André
Yet you have already admitted that the sequence of
steps where DD does the opposite of whatever HHH
returns ARE UNREACHABLE
On 10/9/2026 6:53 AM, Python wrote:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
Yet you have already admitted that the sequence of
steps where DD does the opposite of whatever HHH
returns ARE UNREACHABLE
On 10/9/2026 6:53 AM, Python wrote:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
No, Peter.
That is simply a lie.
You quote my exact words immediately underneath your claim, and they DO
NOT SAY what you claim I "admitted."
I admitted that recursively simulating HHH produces:
HHH -> DD -> HHH -> DD -> ...
I did NOT say that the subsequent steps of DD are "UNREACHABLE."
Not there.
Not anywhere in the text you quoted.
In fact, you already tried this exact dishonest substitution, and when I pointed out that my words did NOT say:
therefore DD does not halt
YOU replied:
"Of course it does not say this."
So you know perfectly well that the conclusion you are now attributing
to me is NOT contained in that quote.
Stop lying about what I admitted.
If you believe "UNREACHABLE" follows from the quoted recursion, then
PROVE THE INFERENCE YOURSELF.
Do not falsely attribute its conclusion to me.
Your quote establishes recursive simulation.
Your word "UNREACHABLE" is YOUR addition.
And that addition is precisely the point under dispute.
Quoting me and then silently inserting your conclusion into my mouth
does not prove it.
It just makes the dishonesty embarrassingly easy to see.
On 10/23/2026 4:15 PM, Python wrote:
If you meant that ... means "have a dotty day", then
you needed to say that you are overriding and superseding
its conventional meaning.
Do not falsely attribute its conclusion to me.
Your quote establishes recursive simulation.
Your word "UNREACHABLE" is YOUR addition.
THAT IS WHAT ... MEANS
On 2026-10-23 16:43, olcott wrote:
On 10/23/2026 4:15 PM, Python wrote:
If you meant that ... means "have a dotty day", then
you needed to say that you are overriding and superseding
its conventional meaning.
Do not falsely attribute its conclusion to me.
Your quote establishes recursive simulation.
Your word "UNREACHABLE" is YOUR addition.
THAT IS WHAT ... MEANS
Um, no. that's not what ... means. You are the one using private definitions. Not Python.
André
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
THAT IS WHAT ... MEANS
Within the above context the ... means infinite recursion.
What I wrote was:
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
The `...` means the recursive pattern continues:
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
It does NOT mean:
-> therefore DD can never reach line 06
How the F is line 06 reached when you agreed that
DD cannot get past its own line 03?
That semantically entails that line 06 is never reached.
you agreed that DD cannot get past its own line 03
How the F is line 06 reached when you agreed that
DD cannot get past its own line 03?
STOP.
I DID NOT AGREE TO THAT.
HHH simulates DD
-> DD calls HHH(DD)
-> HHH simulates DD
-> ...
The `...` means the recursive pattern continues:
Unless you qualified this with
"the recursive pattern continues: five more steps"
then it means continues forever.
Unless you qualified this with
"the recursive pattern continues: five more steps"
then it means continues forever.
Peter, stop playing fucking stupid.
YES.
FOREVER.
I AGREE.
FOR THE NINETEENTH FUCKING TIME:
HHH -> DD -> HHH -> DD -> ...
CONTINUES FOREVER IF YOU KEEP FOLLOWING THE RECURSION.
Now answer the fucking question you just dodged again:
DOES THE HHH(DD) CALLED AT DD LINE 03 RETURN 0?
If you can't see how this answers your own question
then you lack sufficient reasoning skills.
DD simulated by HHH according to the operational
semantics of the C programming language NEVER gets
past its own line 03. This continues FOREVER.
If you can't see how this answers your own question
then you lack sufficient reasoning skills.
No, Peter.
It DOES NOT answer the fucking question.
The question was:--
DOES THE HHH(DD) CALLED AT LINE 03 RETURN 0?
You answered:
DD never gets past line 03.
That is not an answer.
That is the fucking conclusion you are supposed to justify.
So I'll make this simple enough that even your increasingly desperate evasions cannot hide it.
You say:
HHH(DD) == 0
That means:
HHH(DD) RETURNS 0.
Not "thinks about 0."
Not "detects a pattern associated with 0."
Not "0 exists somewhere in an outer invocation."
RETURNS.
ZERO.
Now DD executes:
Halt_Status = HHH(DD);
So:
DOES THAT CALL RETURN 0?
YES OR NO?
Your latest answer:
DD simulated by HHH according to the operational
semantics of the C programming language NEVER gets
past its own line 03. This continues FOREVER.
means that the HHH(DD) at line 03 NEVER RETURNS.
Fine.
Then you have finally selected:
NO.
And therefore:
HHH(DD) at line 03 does not return 0.
So much for your fucking halt decider.
But of course you also want:
HHH detects this infinite recursion,
aborts the simulation,
and returns 0.
So HHH(DD) RETURNS 0 when you need HHH to be a decider,
but HHH(DD) NEVER RETURNS when you need DD stuck at line 03.
Same function.
Same argument.
Two incompatible behaviors.
THAT is your contradiction.
Not mine.
And screaming:
"IT CONTINUES FOREVER"
doesn't fix it.
I FUCKING AGREE THAT IT CONTINUES FOREVER IF HHH DOES NOT RETURN.
That is precisely why you cannot simultaneously claim that HHH RETURNS 0.
For fuck's sake, this is not difficult.
Either:
HHH(DD) at line 03 never returns
in which case your alleged decider fails to return;
or:
HHH(DD) at line 03 returns 0
in which case DD continues to line 06 and halts.
Pick.
One.
You have now spent multiple posts doing absolutely everything except answering that binary question.
And after refusing yet again to answer YES or NO, you tell me that *I*
"lack sufficient reasoning skills."
That's fucking rich.
Your entire alleged refutation now depends on pretending that:
HHH(DD) RETURNS 0
and:
HHH(DD) NEVER RETURNS
can both be true.
They cannot.
No amount of "finite strings", "operational semantics", ellipses,
invented axioms, capitalization, or insults is going to change that.
So cut the bullshit.
DOES THE HHH(DD) AT LINE 03 RETURN 0?
YES OR NO?
If your next answer is anything except YES or NO, I'll take that as confirmation that you understand perfectly well why you cannot answer it.
Thus proving you are either incapable of understanding
the answer or have switched to deception.
On 10/22/2026 7:57 PM, dbush wrote:
On 10/22/2026 8:47 PM, Python wrote:
int main()
{
DD(); // this is the behavior that you are asking about
}
NO, Peter.
For fuck's sake.
NO.
That is NOT the question I asked.
I explicitly removed `main()`, precisely because you kept whining
about "external processes."
Here is the question AGAIN, in YOUR OWN WORDS:
Finite input string: DD
Does that finite string specify a sequence
of steps reaching its final state?
That is not my definition.
That is YOUR definition of what a halt decider determines:
a halt decider operates on a finite string of input source-code to
determine whether or not this finite string of input source-code
specifies a sequence of steps that reach their own final state.
There is no `main()` in my question.
YOU just inserted it.
There is no external process in my question.
YOU just inserted one.
I am asking about the finite source-code string DD and whether, in
YOUR terminology, it "specifies a sequence of steps that reach their
own final state."
And instead of answering, you write:
int main()
{
DD();
}
and announce:
this is the behavior that you are asking about
NO.
IT.
ISN'T.
You no longer even have the excuse that I am imposing conventional
terminology on you.
I am quoting YOUR DEFINITION VERBATIM.
So let's make this almost insultingly simple.
According to you:
A halt decider determines whether its finite
source-code input specifies a sequence of steps
reaching its final state.
Correct?
HHH is a halt decider.
Correct?
DD is its finite source-code input.
Correct?
HHH returns 0.
Correct?
Then what does 0 report?
A) The finite source-code DD specifies a sequence
of steps reaching its final state.
B) The finite source-code DD specifies a sequence
of steps not reaching its final state.
A or B?
Do not show me `main()` again.
Do not tell me what question you would prefer me to be asking.
Do not invent an external process and then accuse me of asking about it. >>>
READ THE FUCKING QUESTION.
A.
Or.
B.
You can't reason with someone who doesn't even understand what the
halting problem is about.
On 3/16/2025 3:54 PM, olcott wrote:
On 3/16/2025 2:18 PM, dbush wrote:
That doesn't change the fact that I want to know if any arbitrary;
algorithm X with input Y will halt when executed directly.
That is a stupid and arbitrary requirement
My words have gotten much better in 1.5 years.
When the halting problem proof is simplified
so that the program-under-test has no input
and fully formalized directly in C then
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 91:05:56 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
1,894 files (564M bytes) |
| Messages: | 2,551,613 |