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
that are not stupid
enough for your bluff. If one detail of your prosentation is wrong or incomplete or missing it is important to focus on that and not care
about the rest.
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.
Most people that review my work merely glance at a couple
of words to artificially contrive a fake rebuttal. Python
has specifically agreed with most of my key points.
He even laid out a complete list of all of my key points
and said which ones that he agreed to. We only have one
more point left and then I can publish. I have to make
sure that I have words that can be understood first.
No one else on any of a dozen forums over 28 years has
ever agreed with anything that I ever said. These people
never wanted to understand what I was saying. They only
wanted to disagree.
that are not stupid
enough for your bluff. If one detail of your prosentation is wrong or
incomplete or missing it is important to focus on that and not care
about the rest.
These "one details" at this point of tens of thousands of rewrites
have gotten to the point of always merely being a failure to fully
understand the exact words that I precisely said.
If you care about the truth and thus do not have disagreement
as your primary goal go look at the recent exchange between
Python and me. You might want to go through this backwards.
I always cross post to comp.theory. In all of the most recent
posts I never deleted a single word of his reply. So you
can just look at my replies to him on comp.theory.
Le 07/10/2026 à 14:45, polcott a écrit :
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.
Most people that review my work merely glance at a couple
of words to artificially contrive a fake rebuttal. Python
has specifically agreed with most of my key points.
He even laid out a complete list of all of my key points
and said which ones that he agreed to. We only have one
more point left and then I can publish. I have to make
sure that I have words that can be understood first.
No one else on any of a dozen forums over 28 years has
ever agreed with anything that I ever said. These people
never wanted to understand what I was saying. They only
wanted to disagree.
that are not stupid
enough for your bluff. If one detail of your prosentation is wrong or
incomplete or missing it is important to focus on that and not care
about the rest.
These "one details" at this point of tens of thousands of rewrites
have gotten to the point of always merely being a failure to fully
understand the exact words that I precisely said.
If you care about the truth and thus do not have disagreement
as your primary goal go look at the recent exchange between
Python and me. You might want to go through this backwards.
I always cross post to comp.theory. In all of the most recent
posts I never deleted a single word of his reply. So you
can just look at my replies to him on comp.theory.
Just one clarification, since you are inviting other people to read our exchange.
Yes, I have deliberately accepted every point of yours that I think can
be accepted, rather than trying to manufacture disagreements. That is
how we managed to isolate the issue.
But this should not be read as my having validated "most of" your
argument with only one minor detail remaining before publication.
The remaining point is the central inference on which your conclusion depends:
HHH's simulated DD specifies a non-halting
sequence of configurations
therefore:
DD does not halt.
I accept the first proposition.
I do not accept that it entails the second, particularly since we also
agree that the actual execution of DD returns when HHH returns 0.
So yes, we have reduced 28 years of discussion to essentially one point.
Unfortunately, it is not a small point. It is the proof.
Le 07/10/2026 à 15:19, olcott a écrit :
On 10/7/2026 7:51 AM, Python wrote:
Le 07/10/2026 à 14:45, polcott a écrit :
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.
Most people that review my work merely glance at a couple
of words to artificially contrive a fake rebuttal. Python
has specifically agreed with most of my key points.
He even laid out a complete list of all of my key points
and said which ones that he agreed to. We only have one
more point left and then I can publish. I have to make
sure that I have words that can be understood first.
No one else on any of a dozen forums over 28 years has
ever agreed with anything that I ever said. These people
never wanted to understand what I was saying. They only
wanted to disagree.
that are not stupid
enough for your bluff. If one detail of your prosentation is wrong or >>>>> incomplete or missing it is important to focus on that and not care
about the rest.
These "one details" at this point of tens of thousands of rewrites
have gotten to the point of always merely being a failure to fully
understand the exact words that I precisely said.
If you care about the truth and thus do not have disagreement
as your primary goal go look at the recent exchange between
Python and me. You might want to go through this backwards.
I always cross post to comp.theory. In all of the most recent
posts I never deleted a single word of his reply. So you
can just look at my replies to him on comp.theory.
Just one clarification, since you are inviting other people to read
our exchange.
Yes, I have deliberately accepted every point of yours that I think
can be accepted, rather than trying to manufacture disagreements.
That is how we managed to isolate the issue.
But this should not be read as my having validated "most of" your
argument with only one minor detail remaining before publication.
I can be accurately stated as you have agreed with most
of the elements of the list of points that establish my
entire foundation.
The remaining point is the central inference on which your conclusion
depends:
HHH's simulated DD specifies a non-halting
sequence of configurations
therefore:
DD does not halt.
You keep paraphrasing this incorrectly I never said that.
You keep paraphrasing this incorrectly I never said that.
You keep paraphrasing this incorrectly I never said that.
You keep paraphrasing this incorrectly I never said that.
You keep paraphrasing this incorrectly I never said that.
I accept the first proposition.
I do not accept that it entails the second, particularly since we
also agree that the actual execution of DD returns when HHH returns 0.
So yes, we have reduced 28 years of discussion to essentially one point. >>>
Unfortunately, it is not a small point. It is the proof.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that
[the correctly simulated] D specifies a non-halting
sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
[the correctly simulated] // inserted for clarity
it can already be inferred from the context.
We can state my view and your assessment of it correctly
in that you have agreed with the exact words stated above
as annotated for clarity.
Yes. I agree with those exact words, including your clarification:
H can abort its simulation of D and correctly report that
[the correctly simulated] D specifies a non-halting
sequence of configurations.
Let's record that as an agreed point.
But about your repeated:
"You keep paraphrasing this incorrectly I never said that."
Fair enough: I will stop using that paraphrase.
However, I did not invent it from nowhere. You previously wrote, verbatim:
HHH's 0 has always meant that "DD does not halt"
That is why I tried to relate your Sipser formulation to "DD does not
halt".
You are now insisting that your exact claim is instead:
[the correctly simulated] DD specifies a non-halting
sequence of configurations.
Fine. I accept that formulation and will use it from now on.
But this actually makes our remaining disagreement even clearer.
I agree that HHH may correctly report that its correctly simulated DD specifies a non-halting sequence of configurations.
I have NOT agreed that this establishes the correctness of HHH as a halt decider, nor that it invalidates the standard halting theorem.
So we now have a useful fixed point:
Your quoted Sipser proposition: AGREED.
Your conclusion about the Halting Problem: NOT AGREED.
And one ambiguity that you can now resolve explicitly:
Does your earlier statement
HHH's 0 has always meant that "DD does not halt"
still stand?
If yes, you need to explain precisely how that statement follows from
the agreed Sipser proposition.
If no, then we should simply withdraw it and stick to your more precise "specifies a non-halting sequence of configurations" formulation.
Either way, repeating "I never said that" doesn't resolve the issue,
because you did explicitly say "DD does not halt".
What matters now is what, exactly, follows from the proposition on which
we actually agree.
Good. Then we can permanently discard:
HHH's 0 means "DD does not halt"
and retain only:
[the correctly simulated] DD specifies a non-halting
sequence of configurations.
Agreed.
Now we have reached the exact logical gap.
You say:
The essence of a halt decider is applying correct
finite string transformations to finite string inputs
to derive accept/reject states.
For the sake of argument: AGREED.
Then you say:
Therefore the Halting Problem proofs have specified
a requirement that has always been outside the scope
of Emil Post computations.
That "Therefore" does not follow.
A finite-string computation can perfectly well decide a property of the object encoded by its finite-string input.--
For example, given a finite string encoding a C program P and its input
x, a finite-string computation may be specified to return:
1 iff execution of P(x) halts
0 otherwise.
Whether such a computation actually exists is precisely the Halting
Problem.
So you cannot establish that this requirement is "outside the scope of computation" merely by defining computation as finite-string transformations. The INPUT to the proposed decider is still a finite
string and its OUTPUT is still a finite string/state.
Your missing premise is therefore:
A Post computation on an encoding <P,x>
cannot be required to decide a semantic property
of the computation encoded by <P,x>.
Where does that premise come from?
It does not follow from your definition of computation.
And if PSR is supposed to make this particular case exceptional, then
you still need to prove:
why, under PSR, the finite string <P,x>
ceases to specify the computation P(x).
Until that is proved, your final "Therefore" is precisely the missing
step, not a consequence of the preceding statements.
Now the missing step is explicit.
You write:
(1) The DD in main() { HHH(DD); }
does not have the same behavior of
(2) The DD in main() { DD(); }
Agreed that these are different executions.
You then say:
(1) is the correct behavior as specified by the
Professor Sipser agreed to specification.
No. The Sipser statement establishes something much narrower:
the correctly simulated DD specifies a non-halting
sequence of configurations.
I agreed to exactly that.
It says nothing whatsoever about:
(1) being the ONLY behavior that a halt decider
can be required to classify.
Yet your next sentence is:
The HP proof has always incorrectly required (2)
When ONLY (1) can be computed by Emil Post.
That "ONLY" is your missing theorem.
Nothing in the Sipser statement establishes it.
In fact, (2) is itself perfectly describable by finite strings:
main() { DD(); }
and its execution is generated by the same finite operational rules of C that you invoke for (1).
So why is:
HHH applying finite rules to a finite encoding of DD
an Emil Post computation, while asking whether the computation
main() { DD(); }
halts is supposedly "outside" the scope of Emil Post computation?
Be careful: saying that no halt decider can successfully decide every--
such question would merely restate the Halting Theorem.
You need the much stronger proposition:
(2) cannot even be the semantic property that a
finite-string computation is REQUIRED to decide.
That does not follow from the Sipser statement.
It does not follow from the fact that HHH's recursive simulation is non- halting.
And it does not follow from defining computation as finite-string transformations.
So we have finally isolated the missing proposition to one word:
ONLY.
Please prove the "ONLY".
Good, we agree that the Sipser statement does not prove the "ONLY".
But we should distinguish two different things:
BEHAVIOR:
what happens when DD() executes.
DECISION:
whether HHH can correctly answer
"Does DD() halt?"
HHH is not required to reproduce DD()'s behavior. It is required, by the standard halting predicate, to decide a property of that behavior.
You say:
HHH1(DD) correctly derives behavior identical to
main() { DD(); }
Fine. That shows that this behavior is not itself outside the scope of
Emil Post computation.
But it does not establish that HHH may not be REQUIRED to decide whether that behavior halts.
Those are different claims:
"HHH does not generate the behavior of DD()"
does not imply:
"HHH cannot be required to decide whether DD() halts."
The second claim is the one you need for your argument.
So the missing "ONLY" is specifically about the scope of the DECISION,--
not about whether the BEHAVIOR can be computed.
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.
A DECIDER is defined by the property it decides,
not by which behavior
it happens to observe while computing its answer.
For the Halting Problem the specification is:
H(<P>,x) = HALTING iff P(x) halts.
How H computes that answer is a completely separate question.
It may simulate P(x), analyze <P>, transform symbols, prove a theorem,
or use any other computable procedure. The specification does not say:
H may report only on behavior occurring inside H.
You have silently replaced:
decide whether P(x) halts
with:
report whether H's simulation of P(x) reaches
a simulated halt state.
Those are different problems.
And saying three times that a halt decider "can only report on the
behavior that it actually sees" does not prove that restriction.
It merely asserts it three times.
So this is now extremely precise:
Please prove that a decider can only decide properties
of behavior that occurs inside its own computation.
Without that theorem, your restriction on halt deciders is simply your premise, not a consequence of Emil Post.
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.
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.
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).
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.
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.
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.
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.
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.
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é
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.
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.
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.
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 95:10:22 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
3,001 files (989M bytes) |
| Messages: | 2,551,712 |