OK Peter. Here is my understanding of your argument. I am deliberately
not rebutting it yet.
You distinguish two things:
1. HHH receives DD as a finite string.
2. HHH may manipulate that finite string only according to finite transformation rules corresponding to the operational semantics of C.
3. You distinguish what HHH can derive from DD in this way from what
happens when DD is actually called directly from main().
4. Your claim is that no valid finite sequence of transformations
performed by HHH on its input DD can derive the behavior of that direct execution.
5. Therefore, requiring HHH to answer according to what DD would do when directly executed from main() requires HHH to determine something that cannot be obtained by the finite-string transformations available to it.
6. You regard that requirement, rather than anything HHH actually
computes from its finite input, as the invalid step in the conventional halting proof.
7. Hence your claim is not merely "HHH cannot decide whether DD halts."
Your stronger claim is that the conventional proof illegitimately
requires HHH to report a fact about a distinct direct execution whose behavior cannot be derived by the permitted finite-string transformation process.
I think that is the distinction you believe I previously missed.
If any part of 1-7 misrepresents your position, please identify the
number and correct it.
If you agree that 1-7 accurately states your argument, then we have
isolated the disagreement precisely and can examine whether step 4 is actually true.
Le 03/10/2026 à 17:06, olcott a écrit :
On 10/3/2026 9:46 AM, Python wrote:
OK Peter. Here is my understanding of your argument. I am
deliberately not rebutting it yet.
You distinguish two things:
1. HHH receives DD as a finite string.
2. HHH may manipulate that finite string only according to finite
transformation rules corresponding to the operational semantics of C.
3. You distinguish what HHH can derive from DD in this way from what
happens when DD is actually called directly from main().
4. Your claim is that no valid finite sequence of transformations
performed by HHH on its input DD can derive the behavior of that
direct execution.
5. Therefore, requiring HHH to answer according to what DD would do
when directly executed from main() requires HHH to determine
something that cannot be obtained by the finite-string
transformations available to it.
6. You regard that requirement, rather than anything HHH actually
computes from its finite input, as the invalid step in the
conventional halting proof.
7. Hence your claim is not merely "HHH cannot decide whether DD
halts." Your stronger claim is that the conventional proof
illegitimately requires HHH to report a fact about a distinct direct
execution whose behavior cannot be derived by the permitted finite-
string transformation process.
I think that is the distinction you believe I previously missed.
If any part of 1-7 misrepresents your position, please identify the
number and correct it.
If you agree that 1-7 accurately states your argument, then we have
isolated the disagreement precisely and can examine whether step 4 is
actually true.
That is a 100-fold better understanding of my work than
any other human has ever presented. It even much more
succinctly presents my view much better than the best LLM.
Then let's keep those seven points as the agreed description of your position.
That is useful because it means we no longer have to argue about whether
I understand what you are claiming.
And I agree that your actual claim is more subtle than simply saying
that HHH somehow "solves the halting problem".
Your claim, as I now understand it, is specifically that the
conventional diagonal argument asks HHH to report the behavior of a computation distinct from the finite-string computation that HHH can actually derive from its input DD.
So let's focus entirely on point 4:
No valid finite sequence of transformations performed
by HHH on its input DD can derive the behavior of the
direct execution of DD from main().
That is now the precise proposition we disagree about.
And I think we can examine that proposition without misrepresenting your position and without appealing to authority on either side.
We finally have a sharply defined question.
No valid finite sequence of transformations performed
by HHH on its input DD can derive the behavior of the
direct execution of DD from main().
Le 03/10/2026 à 17:52, olcott a écrit :
On 10/3/2026 10:24 AM, Python wrote:
Le 03/10/2026 à 17:06, olcott a écrit :
On 10/3/2026 9:46 AM, Python wrote:
OK Peter. Here is my understanding of your argument. I am
deliberately not rebutting it yet.
You distinguish two things:
1. HHH receives DD as a finite string.
2. HHH may manipulate that finite string only according to finite
transformation rules corresponding to the operational semantics of C. >>>>>
3. You distinguish what HHH can derive from DD in this way from
what happens when DD is actually called directly from main().
4. Your claim is that no valid finite sequence of transformations
performed by HHH on its input DD can derive the behavior of that
direct execution.
5. Therefore, requiring HHH to answer according to what DD would do >>>>> when directly executed from main() requires HHH to determine
something that cannot be obtained by the finite-string
transformations available to it.
6. You regard that requirement, rather than anything HHH actually
computes from its finite input, as the invalid step in the
conventional halting proof.
7. Hence your claim is not merely "HHH cannot decide whether DD
halts." Your stronger claim is that the conventional proof
illegitimately requires HHH to report a fact about a distinct
direct execution whose behavior cannot be derived by the permitted
finite- string transformation process.
I think that is the distinction you believe I previously missed.
If any part of 1-7 misrepresents your position, please identify the >>>>> number and correct it.
If you agree that 1-7 accurately states your argument, then we have >>>>> isolated the disagreement precisely and can examine whether step 4
is actually true.
That is a 100-fold better understanding of my work than
any other human has ever presented. It even much more
succinctly presents my view much better than the best LLM.
Then let's keep those seven points as the agreed description of your
position.
That is useful because it means we no longer have to argue about
whether I understand what you are claiming.
And I agree that your actual claim is more subtle than simply saying
that HHH somehow "solves the halting problem".
Your claim, as I now understand it, is specifically that the
conventional diagonal argument asks HHH to report the behavior of a
computation distinct from the finite-string computation that HHH can
actually derive from its input DD.
So let's focus entirely on point 4:
No valid finite sequence of transformations performed
by HHH on its input DD can derive the behavior of the
direct execution of DD from main().
That is now the precise proposition we disagree about.
And I think we can examine that proposition without misrepresenting
your position and without appealing to authority on either side.
We finally have a sharply defined question.
Yes. You were able to precisely axiomatize my position such
that even if it comes at the end of a 75 page conversation
with an LLM there will be no issue with "lost in the middle".
I tested this at the end of a 75 page conversation with an LLM.
LLMs can pay very close attention to a short list of short axioms.
Over the last 28 years almost everyone would merely glance
at a few of my words before artificially contriving a
rebuttal that totally ignores most of what I have said.
; No valid finite sequence of transformations performed
; by HHH on its input DD can derive the behavior of the
; direct execution of DD from main().
This can be more sharply defined as:
No finite string transformation rules inference steps
that are constrained by the operational semantics of
the C programming language can be applied by HHH to
its input finite string DD such that this input DD
ever reaches its own "return" instruction final halt
state.
Yes. That is sharper, and I am happy to use that formulation.
So let me restate point 4 exactly in your stronger form:
No finite string transformation rules inference steps
that are constrained by the operational semantics of
the C programming language can be applied by HHH to
its input finite string DD such that this input DD
ever reaches its own "return" instruction final halt
state.
For the particular recursive simulation you have described, I agree with that statement.
In fact, I think this is an important point of progress, because I do
not need to dispute it in order to dispute your conclusion.
HHH simulates DD.
The simulated DD reaches:
Halt_Status = HHH(DD);
To complete that C statement, the simulated invocation of HHH(DD) must return a value.
But that simulated HHH begins another simulation of DD, which reaches
the same call again:
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
...
Therefore, if we simply continue applying those operational-semantic transitions, no simulated DD in this recursively expanding computation reaches its own return instruction.
I agree.
So let us make that an additional agreed proposition:
8. In HHH's recursively nested simulation of DD,
continued application of the C operational semantics
never causes any simulated DD to return normally.
Now comes the question on which everything depends.
What exactly follows from proposition 8?
There are two possible conclusions:
A. The recursively nested simulation performed by HHH
does not terminate unless HHH aborts it.
or:
B. DD itself is a non-halting program, so HHH may
correctly return "DD does not halt".
I agree with A.
What I do not yet see established is A -> B.
And notice that this is no longer a disagreement about whether HHH can derive the behavior described in A using finite-string transformations.
It plainly can.
Nor is it a disagreement about whether simulated DD reaches its return instruction.
I agree that it does not.
The remaining question is solely whether:
simulated DD cannot return while waiting for
the recursively computed value HHH(DD)
entails:
DD does not halt when HHH(DD) returns the value
"non-halting".
Those are not obviously the same proposition.
Indeed, consider what happens when your detector fires.
Before the detector fires, we have:
HHH(DD)
simulates DD
waits for HHH(DD)
simulates DD
waits for HHH(DD)
...
Your finite-string inference mechanism recognizes the infinite-recursion pattern.
Fine.
HHH then aborts that simulation.
Fine.
Now there is a crucial fork.
If HHH merely aborts and never returns a value, then HHH has not decided
DD.
But if HHH returns:
0 = "DD does not halt"
then the invocation of HHH(DD) that called the simulator has terminated.
Now consider DD under the very C semantics we have agreed to use:
Halt_Status = HHH(DD);
If HHH returns 0, this statement completes.
Then:
if (Halt_Status)
is false, and DD reaches its return instruction.
This does NOT require the DD that HHH aborted inside its private
simulation to resume execution.
That simulated instance is gone.
It concerns the caller to which HHH returns its result.
So I think we can sharpen our disagreement even further.
I accept your new point 4.
I accept:
No simulated DD in the un-aborted recursive simulation
reaches its return instruction.
I accept:
HHH can recognize the recursive nontermination pattern
and abort that simulation.
The only remaining disputed implication is:
Because simulated DD cannot reach return before
HHH(DD) has produced an answer,
therefore:
HHH may produce the answer "DD does not halt".
That is the implication I want you to justify.
In particular, I would like you to answer one extremely concrete
question, using only C operational semantics:
Suppose the outermost invocation of HHH(DD) detects your recursion
pattern, aborts its internal simulation, and returns 0 to its caller.
What C operational-semantic rule prevents that caller from completing:
Halt_Status = HHH(DD);
with:
Halt_Status = 0
and proceeding to the following statement?
If your answer is:
"There is no such caller because the whole recursive
chain was aborted",
then we need to distinguish very carefully between:
aborting HHH's internal simulated DD
and:
aborting the actual invocation of DD that called HHH.
Because if HHH aborts its caller
rather than returning a value to it,
then HHH has changed the computation instead of returning a halting
decision about it.
This is now sufficiently precise that I don't think we need to discuss
the halting theorem, diagonalization, Post, or even Sipser yet.
We can settle this locally from the operational semantics of the C call:
Halt_Status = HHH(DD);
You have established that simulated DD cannot get past that statement
while HHH is recursively simulating.
Agreed.
The remaining question is:
What happens to the caller according to C semantics when HHH stops simulating and returns its answer?
I think we can now reduce the entire disagreement to this.
We agree that:
1. HHH simulates DD.
2. Inside that simulation, DD calls HHH(DD), producing
recursive simulation.
3. No simulated DD reaches its return instruction before
HHH detects this pattern.
4. HHH aborts its internal simulation and returns 0.
5. If DD is actually executing, that 0 completes:
Halt_Status = HHH(DD);
so DD takes the non-looping branch and returns.
You explicitly agree that:
int main() { DD(); }
terminates.
Therefore the only disagreement is what HHH's 0 means.
If it means:
"DD does not reach return inside HHH's recursive
simulation before HHH aborts it"
then HHH may be correct, but that is not the halting predicate.
If it means:
"DD does not halt"
then it is false, because you agree that DD terminates when HHH returns 0.
Calling that terminating execution "out-of-scope" does not solve the problem. Its behavior follows by a finite application of ordinary C semantics:
DD
-> HHH(DD)
-> HHH returns 0
-> Halt_Status = 0
-> return 0
So there is one concrete question:
Which transition in that finite sequence violates either C operational semantics or your finite-string transformation requirement?
If none does, then DD's terminating behavior is not outside computation.
What you have proved is only that DD does not terminate inside HHH's recursively nested simulation before HHH aborts that simulation.
That is a property of HHH's simulation procedure, not a proof that DD
itself does not halt.
Thank you, Peter. And I think we have now isolated the disagreement
about as far as it can be isolated.
I accept your clarification of the Sipser statement:
H can correctly report that the [correctly simulated] D
specifies a non-halting sequence of configurations.
And I accept that your simulated DD never reaches return.
But we also now explicitly agree that:
int main() { DD(); }
does terminate when HHH returns 0.
So there is no longer any disagreement about either execution.
Our remaining disagreement is entirely this claim:
The execution of DD() is outside the scope of finite-string
computation because the executing process is not itself a
finite string input to HHH.
That is the point I reject.
The executing process does not need to be a finite string.
Its DESCRIPTION is the finite string.
That is the entire purpose of encoding programs and computations.
Otherwise the same objection would apply to every universal simulator:
P(x) is an executing process, not the finite string <P,x>
given to U.
Yet computation theory relates them precisely by saying that the finite description <P,x> specifies the computation P(x).
And in this particular case we do not even need an infinite argument. We both agree on the finite semantic derivation:
DD
-> calls HHH(DD)
-> HHH returns 0
-> Halt_Status = 0
-> DD returns 0
Every program description involved is finite, every configuration is finitely representable, and every transition follows from finite rules.
So I think the whole issue has now reduced to one proposition:
Does a finite program description specify the behavior
of the computation obtained by executing that program?
Standard computability theory says yes.
Your argument requires the answer to be no specifically when the
execution and HHH's internal recursive simulation have different behavior.
But if the answer is no, HHH is simply classifying the behavior of its
own simulation rather than the halting behavior specified by DD.
Thus I accept your result about the simulated DD.
What I reject is the identification:
"the simulated DD inside HHH never returns"
=
"the finite string DD specifies a non-halting computation."
Your own agreement that:
int main() { DD(); }
terminates demonstrates why those two propositions are different.
I think that is now the entire disagreement, with nothing else hidden underneath it.
I think we have isolated the fundamental disagreement.
Your claim is:
The HP proof falsely assumes that the input to a halt
decider always specifies a single behavior, even under
pathological self-reference.
I don't think the proof makes that assumption.
Assume a total correct halt decider:
H(P,x) = 1 iff P(x) halts.
Define:
D(x)
{
if (H(x,x))
while (1) {}
else
return;
}
Now consider D(D):
H(D,D) = 1 => D(D) loops => H is wrong.
H(D,D) = 0 => D(D) returns => H is wrong.
H diverges => H is not a total decider.
That is the entire diagonal contradiction.
Notice that it says nothing about HOW H computes its answer. In
particular, it never assumes that H recursively simulates D(D).
This is where I think your HHH changes the predicate.
We agree that:
1. DD recursively simulated inside HHH never reaches return.
2. DD actually executing does reach return when HHH returns 0.
Those are two different computations.
If HHH's 0 means:
"DD does not reach return inside my recursive simulation"
then I accept that HHH may be correct.
But if it means:
"DD does not halt"
then it is false, because we agree:
DD -> HHH(DD) -> 0 -> DD returns.
Calling this execution "out-of-scope" does not change the predicate used
in the halting theorem.
The finite description <P,x> specifies the computation P(x).
The
executing process need not itself be the finite input string.
So your observation establishes:
HHH's simulation of DD does not halt,
while:
DD executing and calling HHH does halt.
But that does not refute the diagonal proof.
It shows that HHH is
deciding a property of its internal simulation rather than the required predicate:
"Does the specified computation halt?"
The proof assumes only that a total H correctly answers that question
and then proves that no such H can exist.
Pathological self-reference is not an overlooked exception to the proof.
It is exactly what makes the contradiction possible.
One important ambiguity is now gone.
You say explicitly:
HHH's 0 has always meant that "DD does not halt".
So let's use exactly that meaning.
You also agree that:
int main() { DD(); }
halts when HHH(DD) returns 0.
Therefore:
HHH(DD) = 0 means "DD does not halt"
HHH(DD) = 0 causes DD to halt.
That is already the diagonal contradiction.
Nothing else has to be "reached".
The proof does NOT say:
H returns 0
-> some contradiction state is eventually reached.
It says:
H returns 0
-> by H's specification, D does not halt
-> by D's definition, D halts.
Likewise:
H returns 1
-> by H's specification, D halts
-> by D's definition, D does not halt.
"Contradiction" is the logical incompatibility between those
propositions, not a machine configuration.
Your remaining escape is therefore entirely this:
Although HHH(DD)=0 means "DD does not halt",
the terminating DD() is not the DD behavior that
HHH(DD) is required to classify.
But then we need a precise definition of:
"DD does not halt"
because we agree that an execution of DD does halt.
Saying that the terminating execution is "outside the domain of HHH(DD)" simply restricts the predicate being decided.
So I think there is now exactly one question left:
What computation does the proposition
"DD does not halt" refer to?
If it refers to DD executing with the actual semantics of HHH, your 0 is wrong.
If it refers only to DD inside HHH's recursively nested simulation, then
you have defined a different halting predicate.
There is no third possibility supplied by saying that the contradiction
is "unreachable", because the contradiction was never an execution state that had to be reached.
P.S. About the massive crossposting: posting the same article to
numerous newsgroups is not a distributed backup strategy. Usenet groups
are not separate servers, so if your concern is preserving 30,000 hours
of work, tar, git, and a couple of independent backups would be
considerably more effective than adding another dozen groups to the Newsgroups: header.
And, unfortunately, 30,000 hours is evidence of persistence, not
correctness or value. In mathematics and theoretical computer science,
an argument is worth exactly what its proof is worth. Spending 28 years
on a false premise does not make the premise 28 years stronger.
So perhaps fewer newsgroups and one actual proof would provide rather
better redundancy.
The Hehner/Stoddart references are interesting, and I checked them.
There really is a similarity: Stoddart explicitly describes the
dissenting position as agreeing that the usual halt function cannot be implemented, while arguing that its specification is inconsistent rather than treating this simply as an undecidable computable predicate.
So I won't dismiss the comparison.
But this does not establish your particular argument.
In fact, Hehner makes an important point that differs from yours: he
says the contradiction remains even when `halt` is treated as an unimplemented specification. His conclusion is that the relevant self- referential specifications are inconsistent.
Your claim is different:
the contradiction is never reached, because the
finite-string computation performed by HHH has a
different behavior.
That still leaves exactly the issue we have isolated.
You now explicitly say:
HHH(DD)=0 means "DD does not halt".
And you explicitly agree:
HHH(DD)=0 -> DD returns.
Therefore:
HHH says DD does not halt
while DD halts.
You answer this by saying that the terminating DD is not the behavior
HHH is required to classify.
Fine — but that changes the meaning of "DD does not halt".
The diagonal argument itself remains:
H(D,D)=1 -> D loops -> H is wrong
H(D,D)=0 -> D returns -> H is wrong
H diverges -> H is not a decider
Nothing in that argument requires a "contradiction state" to be reached
by H.
So I think you now need to establish your genuinely novel claim rather
than cite Hehner or Stoddart:
Why does the finite description DD cease to specify
the ordinary execution of DD specifically because HHH
occurs in the self-reference?
That is the missing theorem.
Your finite-string account shows what HHH's internal simulation does. It does not yet establish that the ordinary semantic relation between a
program description and its execution becomes invalid under self-reference.
If you can prove THAT, you have something substantial to publish.
But Hehner and Stoddart cannot supply that proof for you merely because
they also criticize the conventional interpretation of the halting
argument.
Peter, I am not ignoring your distinction. I am pointing out that you
keep switching between two different claims.
A few messages ago you explicitly wrote:
HHH's 0 has always meant that "DD does not halt"
Now you replace that with:
HHH correctly reports that [its correctly simulated] DD
specifies a non-halting sequence of configurations.
Those are not the same proposition.
We already agreed on the second one.
So please choose exactly which proposition HHH(DD)=0 asserts:
A. DD does not halt.
or:
B. HHH's simulation of DD produces a non-halting
sequence of configurations.
If B, we have no disagreement about HHH's result. But B is not the
standard halting predicate.
If A, then we must ask what "DD" denotes in A. We agree that:
main() { DD(); }
terminates when HHH(DD) returns 0.
Your answer is:
This is NOT the D that is under test.
But of course the executing process is not literally HHH's finite-string input. Nobody ever claimed it was.
The finite string is the DESCRIPTION of the computation whose halting behavior is being asked about:
finite description <P,x>
|
v
computation P(x)
Saying that P(x) is not literally the finite string <P,x> does not put
P(x) "outside computation".
Otherwise a universal machine could never compute anything about the
machine encoded by its input.
And this sentence still needs proof:
The DD executed from main is outside of the domain
of any Emil Post halt decider.
It does not follow from:
computations use finite strings and finite
transformation rules.
You need an additional theorem establishing:
finite descriptions can specify ordinary executions,
EXCEPT when pathological self-reference occurs.
That exception is precisely your novel claim. You cannot use the claimed exception as its own proof.
The Sipser quotation doesn't establish it either. I accept the
conditional statement you quote: if H correctly determines that its simulated D produces a non-halting sequence, it can correctly report
that fact.
Fine.
But that establishes B, not A.
And your dog analogy actually illustrates the problem rather nicely:
If cats were dogs, cats would bark.
Certainly. But that does not establish:
cats are dogs.
Likewise I can accept:
If HHH's simulated DD produces a non-halting sequence,
HHH may correctly report that simulated sequence
as non-halting.
That does not establish:
DD does not halt.
To get from the first proposition to the second, you need precisely the additional premise that the behavior of HHH's simulated DD is the
halting behavior denoted by DD.
But we already agree that the two behaviors differ:
simulated DD: never reaches return
executing DD: HHH returns 0, then DD returns
So the dog analogy doesn't rescue the implication. It highlights the
missing premise.
We can therefore reduce the entire remaining disagreement to:
You: B entails A because under PSR only the behavior
derivable inside HHH from its finite input counts.
Me: B does not entail A. You still need to prove
that PSR exception.
That is the missing step.--
Everything else is now secondary.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 93:07:30 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
2,349 files (779M bytes) |
| Messages: | 2,551,657 |