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
On 9/30/26 5:47 AM, Alan Mackenzie wrote:Exactly!
Chris M. Thomasson <[email protected]> wrote:
On 9/29/2026 2:43 AM, Alan Mackenzie wrote:
[ Followup-To: set ]
In comp.theory Chris M. Thomasson <[email protected]>
wrote:
On 9/24/2026 3:45 PM, dart200 wrote:
On 9/24/26 3:21 PM, Chris M. Thomasson wrote:
[ .... ]
You really are PO! ;^o Woha!
i really am not polcott,
Are you sure? You two are very much, alike.
If you'd read any great deal of both of them, you would see straight
away they're not the same poster.
You've repeated that assertion so much it's in danger of becoming spam.
[ .... ]
Why do they [polcott and dart200] seem to act alike?
What they have in common is a lack of respect for proven mathematics and
the achievements of great intellects of previous generations. Also, both
acting like the greats can never be wrong is when objectivity turns into propaganda, alan
for the record: turing wrote the most impactful math paper in human
history. certainly others were great as well, not discrediting them, but mechanical computing and the ability to imbue discrete logic into
objects, along with the sheer computational power of those objects, has clearly has the most significant impact on our progression as a species. narcissistic asshates scrambling for "muh AGI" have little appreciation
for just how miraculous computing already is...
and i'm _only_ improving on it u dipshit, nothing about my claims even remotely diminishes the the significance of his work.
the fact academics aren't even remotely open the idea truly exemplifies
how broken modern academia is.
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.
Le 02/10/2026 à 15:24, olcott a écrit :
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.
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.
Le 02/10/2026 à 16:15, olcott a écrit :
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.
Peter, then demonstrate that.
On 10/2/2026 9:32 AM, Python wrote:
Le 02/10/2026 à 16:15, olcott a écrit :It is now up to you to prove to me that you understand
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.
Peter, then demonstrate that.
my words. Feel free to ask for clarifications.
This
will be the last thing that I say to you until you
do that. I have very important construction work that
must be done today. I have to pour five bags of concrete
while I am on an oxygen tank.
Quote the specific words of yours that I failed to pay attention to, and
explain what they mean that my response failed to address.
You wrote:
"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."
I explicitly agreed with that premise.
You then wrote:
"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()."
That is the conclusion I challenged.
My objection is very specific: the behavior of DD when executed from
main() is itself generated by successive applications of the operational
semantics of C.
So there is no "artificially contrived rebuttal" here.
If I have misunderstood what you mean by "derive the behavior of DD
directly executed in main()", define that phrase precisely and show
where my interpretation differs from yours.
That would resolve the issue immediately.
On 10/2/2026 10:51 AM, olcott wrote:
On 10/2/2026 9:32 AM, Python wrote:
Le 02/10/2026 à 16:15, olcott a écrit :It is now up to you to prove to me that you understand
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.
Peter, then demonstrate that.
my words. Feel free to ask for clarifications.
He did exactly that below in the part that you dishonestly erased.
This indicates to me and everyone else reading that you're not
interested in an honest dialogue, and have effectively admitted that everything he's saying is correct.
Le 02/10/2026 à 16:15, olcott a écrit :
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.
Peter, then demonstrate that.
Quote the specific words of yours that I failed to pay attention to, and explain what they mean that my response failed to address.
You wrote:
"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."
I explicitly agreed with that premise.
You then wrote:
"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()."
That is the conclusion I challenged.
My objection is very specific: the behavior of DD when executed from
main() is itself generated by successive applications of the operational semantics of C.
So there is no "artificially contrived rebuttal" here.--
If I have misunderstood what you mean by "derive the behavior of DD
directly executed in main()", define that phrase precisely and show
where my interpretation differs from yours.
That would resolve the issue immediately.
On 10/2/2026 10:51 AM, olcott wrote:
On 10/2/2026 9:32 AM, Python wrote:
Le 02/10/2026 à 16:15, olcott a écrit :It is now up to you to prove to me that you understand
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.
Peter, then demonstrate that.
my words. Feel free to ask for clarifications.
He did exactly that below in the part that you dishonestly erased.
Good. Now your argument is precise enough that I can see exactly what
you mean.
I agree with your simulation invariant.
Given:
DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
goto HERE;
return Halt_Status;
}
and assuming that HHH attempts to determine the behavior of DD by
correctly simulating DD according to the operational semantics of C,
then we get:
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
...
Therefore the simulated DD never gets past line 03.
I agree.
But notice what has just been established.
It is not that the behavior of DD cannot be represented or derived step
by step using the operational semantics.
Quite the opposite: the operational semantics gives us the execution
trace above perfectly well.
And that execution trace tells us something very specific:
HHH(DD) does not terminate.
That is exactly why this particular HHH cannot be a halt decider.
A halt decider is required to terminate and return an answer for every program in its claimed domain. If HHH tries to determine the behavior of
DD by the recursive simulation you describe, then on input DD it does
not return an answer at all.
It enters:
HHH(DD)
; simulate DD
; simulated HHH(DD)
; simulate DD
; simulated HHH(DD)
; ...
So I accept your software-engineering argument completely:
DD correctly simulated by this HHH cannot reach its own return instruction.
But this establishes the nontermination of HHH(DD), not the correctness
of HHH as a halt decider.
In fact, it demonstrates the exact failure of this proposed decision procedure on the diagonal input.
There is also an important distinction concerning your earlier phrase
"DD directly executed in main()".
The program you have now posted does not directly execute DD from main().
It contains:
void main()
{
HHH(DD);
}
not:
void main()
{
DD();
}
Those are two different computations and must not be conflated.
Call the first one A:
main()
; HHH(DD)-> simulate DD
-> simulated HHH(DD)
-> simulate DD
-> ...
Your invariant establishes that A does not terminate, assuming HHH
continues performing the recursive simulation you specified.
Now consider the genuinely direct execution B:
main()
; DD()-> HHH(DD)
If HHH implements the recursive simulation procedure above, HHH(DD)
again fails to return. Therefore the directly executed DD also never
gets past line 03.
Again, nothing here is outside the operational semantics of C.
On the contrary, every step of this reasoning is obtained from those operational semantics.
This is why I now think the exact point of disagreement is much narrower than it initially appeared.
I accept your invariant:
DD simulated by HHH cannot get past line 03.
I accept the corresponding infinite execution trace:
HHH(DD)
; DD-> HHH(DD)
-> DD
-> HHH(DD)
-> ...
What I do not see is how you get from this to the conclusion that HHH
has decided whether DD halts.
It has not.
It is still computing.
If you instead intend HHH to recognize this recursive situation, abort
the simulation, and return an answer, then that is a different algorithm from the indefinitely recursive simulation described above.
In that case, please specify exactly what happens.
For example, suppose HHH detects the recursion and returns 0, meaning
"DD does not halt".
Then the simulated DD receives:
Halt_Status = 0;--
and executes:
if (Halt_Status)
goto HERE;
The condition is false, so it continues to:
return Halt_Status;
and terminates.
Thus returning 0 makes DD terminate.
Alternatively, suppose HHH returns 1, meaning "DD halts".
Then DD receives:
Halt_Status = 1;
and executes:
HERE: goto HERE;
forever.
Thus returning 1 makes DD not terminate.
And if HHH returns neither 0 nor 1 because it continues recursively simulating DD, then HHH itself does not halt and therefore is not a halt decider.
So we have the three possibilities:
HHH(DD) returns 0
DD continues past line 03 and terminates.
HHH(DD) returns 1
DD reaches the loop and does not terminate.
HHH(DD) never returns
HHH is not a halt decider.
That is the diagonal contradiction in ordinary software-engineering terms.
No appeal to some mysterious execution outside the operational semantics
is required.
In fact, your simulation invariant is perfectly compatible with the conventional result. It demonstrates what happens when one tries to implement the supposed decider by recursively simulating the diagonal program: the attempted decision procedure itself fails to terminate.
So I am not disputing your execution trace. I am granting it.
The question I am asking is now extremely concrete:
At exactly what point in this trace does HHH stop simulating DD and
return its halt/no-halt answer?
If it never does, HHH is not a halt decider.
If it does, please state:
1. what finite rule causes HHH to stop,
2. what value HHH returns, and
3. whether that value means that DD halts or does not halt.
Then we can simply continue the C execution from line 03 and check
whether the answer is correct.
Now the disagreement is completely explicit.
You say:
Nothing because the whole recursive chain has been aborted.
That is precisely the problem.
If HHH aborts the entire simulated computation, then it has not
established that DD itself specifies a non-halting computation. It has established that the particular simulation procedure being performed by
HHH would recurse indefinitely unless HHH intervenes.
Those are different propositions.
Consider your quoted statement:
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 D
specifies a non-halting sequence of configurations.
I have no objection to that statement as written.
The crucial phrase is:
correctly determines
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
...
Therefore the simulated DD never gets past line 03.
I agree.
That phrase assumes the very thing that must be proved.
For an ordinary infinite loop such as:
D()
{
while (1) {}
}
H may have some sound method proving that D specifies a non-halting computation.
But DD is different because the behavior of DD depends on the result returned by HHH(DD).
You cannot establish that DD is non-halting merely by observing that recursive simulation occurs when HHH attempts to simulate DD. You must establish that the actual computation specified by DD is non-halting.
And this brings us directly to your second claim:
When HHH is called from DD() this is not the input
finite string to HHH and HHH is only accountable
Emil Post computations.
This does not solve the problem.
The source text or machine description of DD is a finite string.
The description of HHH is also a finite string.
The configuration representing:
DD executing line 03 and invoking HHH(DD)
is finite.
The next configuration is finite.
Every individual configuration in the recursive computation is finite.
Every transition between configurations is determined by finite rules.
Thus:
DD -> HHH(DD) -> simulated DD -> simulated HHH(DD) -> ...
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
...
is perfectly representable as a sequence of finite configurations
generated by finite transition rules.
The fact that the sequence may be infinite does not violate Post's formulation.
That distinction is essential.
"Finite string transformations" does NOT mean that every computation
must contain only finitely many transformations.
It means that computation proceeds by finitely specified operations on finite symbolic configurations.
A Turing machine that runs forever is still a Turing-machine computation.
Likewise, an infinite Post production sequence does not suddenly become something outside computation theory merely because it has infinitely
many successive configurations.
Otherwise the halting problem would become meaningless by definition:
every non-halting computation would simply be declared "outside the
scope" because it contains infinitely many steps.
There is an even more fundamental problem with saying:
All of it seems to be referring to DD() calling HHH
and this violates Emil Post.
DD calling HHH cannot simultaneously be:
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
DD calls HHH(DD)
HHH simulates DD
...
1. forbidden as something outside the computational model,
and
2. something HHH correctly simulates according to the operational
semantics of C.
Your own simulation trace contains exactly that call:
simulated DD()
invokes simulated HHH(DD)
You used that transition to establish your invariant:
DD correctly simulated by HHH cannot possibly
reach past its own line 03.
So the call cannot suddenly become inadmissible when we ask what follows from it.
If:
simulated DD -> simulated HHH(DD)
is a legitimate transition when establishing your invariant, then it
remains a legitimate transition when analyzing what HHH's answer means.
There is also a deeper issue with:
Nothing because the whole recursive chain has been aborted.
Suppose HHH reaches some finite configuration C and recognizes the
recursive pattern.
HHH then performs an operation such as:
abort simulation;
return 0;
Fine. That is itself just another finite computational transition.
Now ask what proposition the returned 0 asserts.
If it asserts:
"The simulation I just aborted would have continued recursively"
then I agree.
But that is not a solution to the halting problem.
A halt decider must answer the relevant question about its input computation:
"Does the computation specified by DD halt?"
If 0 means:
"DD does not halt"
then the answer must correspond to the semantics of DD.
And DD contains:
Halt_Status = HHH(DD);
Therefore the value returned by HHH is semantically relevant to DD's behavior.
You cannot say both:
HHH returns 0 as the answer about DD
and:
DD never receives that 0 because I aborted DD.
The latter describes what HHH did to
its private simulation.
It does not establish what DD does when HHH returns 0.
This is the distinction between:
aborting a simulation of P
and:
proving that P itself does not halt.
For example, I can write a simulator S that simulates any program for
1000 steps and then aborts.
When S aborts the simulation of P, obviously P does not receive anything from S.
But that tells us absolutely nothing about whether P itself would
eventually halt.
Your proposed HHH needs something stronger: a sound criterion proving
that the aborted infinite-looking simulation corresponds to a genuinely non-halting computation of DD.
And with DD, that is exactly where diagonalization matters.
If HHH returns "non-halting", DD is defined to take the non-looping branch.
If HHH returns "halting", DD is defined to take the looping branch.
Aborting HHH's internal simulation does not remove this semantic
dependency.
It merely prevents the simulated copy from continuing.
So I think we have finally isolated the exact issue.
I agree that HHH may abort its own simulation.
I agree that the recursive simulation, if allowed to continue, produces
an unbounded sequence of nested simulations.
I agree that HHH can detect some such patterns if you provide an
effective detection rule.
What has not been established is the following implication:
"HHH's simulation of DD would recurse forever"
therefore
"DD specifies a non-halting computation"
because DD's behavior depends on the answer produced by HHH.
And appealing to Emil Post does not eliminate that dependency. The
source of DD, the source of HHH, every configuration involved, and every individual transition are all finite symbolic objects governed by finite rules.
So there is now one very precise question:
When HHH aborts the recursive simulation and reports "DD does not halt", what finite-string computation establishes that this statement is about
the behavior specified by DD, rather than merely about the
nontermination of the simulation that HHH has just aborted?
That is the missing step.
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()
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.
On 02/10/2026 15:28, olcott wrote:
On 10/1/2026 10:05 PM, dart200 wrote:
On 10/1/26 5:28 PM, Chris M. Thomasson wrote:
On 10/1/2026 3:54 PM, dart200 wrote:
[...]
Are you saying that the halting problem is not solvable? If so, so
what?
it is solvable for an enumerable set of machines that includes all
possible output sequences, it is not solvable for all possible machines
The key mistake of the halting theorem is that
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()
No, it isn't. The halting problem says nothing about "DD()" or "main()".
The halting problem asks "How can one determine whether a computation
halts?"
On 10/7/2026 5:40 AM, Mikko wrote:
On 02/10/2026 15:28, olcott wrote:
On 10/1/2026 10:05 PM, dart200 wrote:
On 10/1/26 5:28 PM, Chris M. Thomasson wrote:The key mistake of the halting theorem is that
On 10/1/2026 3:54 PM, dart200 wrote:
[...]
Are you saying that the halting problem is not solvable? If so, so
what?
it is solvable for an enumerable set of machines that includes all
possible output sequences, it is not solvable for all possible machines >>>
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()
No, it isn't. The halting problem says nothing about "DD()" or "main()".
The halting problem asks "How can one determine whether a computation
halts?"
Here is the same thing from Linz where H and Ĥ.embedded_H are
also based on UTM simulation of their inputs.
*From the bottom of page 319 has been adapted to this*
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
On 10/7/2026 5:40 AM, Mikko wrote:
On 02/10/2026 15:28, olcott wrote:
On 10/1/2026 10:05 PM, dart200 wrote:
On 10/1/26 5:28 PM, Chris M. Thomasson wrote:The key mistake of the halting theorem is that
On 10/1/2026 3:54 PM, dart200 wrote:
[...]
Are you saying that the halting problem is not solvable? If so, so
what?
it is solvable for an enumerable set of machines that includes all
possible output sequences, it is not solvable for all possible machines >>>
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()
No, it isn't. The halting problem says nothing about "DD()" or "main()".
The halting problem asks "How can one determine whether a computation
halts?"
Here is the same thing from Linz where H and Ĥ.embedded_H are
also based on UTM simulation of their inputs.
*From the bottom of page 319 has been adapted to this*
On 09/10/2026 14:40, olcott wrote:
On 10/9/2026 3:18 AM, Mikko wrote:
On 07/10/2026 15:25, polcott wrote:
On 10/7/2026 5:40 AM, Mikko wrote:
On 02/10/2026 15:28, olcott wrote:
On 10/1/2026 10:05 PM, dart200 wrote:
On 10/1/26 5:28 PM, Chris M. Thomasson wrote:
On 10/1/2026 3:54 PM, dart200 wrote:
[...]
Are you saying that the halting problem is not solvable? If so, >>>>>>>> so what?
it is solvable for an enumerable set of machines that includes
all possible output sequences, it is not solvable for all
possible machines
The key mistake of the halting theorem is that
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()
No, it isn't. The halting problem says nothing about "DD()" or
"main()".
The halting problem asks "How can one determine whether a computation >>>>> halts?"
Here is the same thing from Linz where H and Ĥ.embedded_H are
also based on UTM simulation of their inputs.
*From the bottom of page 319 has been adapted to this*
Earlier on that page Linz says: "Simply stated, the problem is: given
the description of a Turing machine M and an input w, does M, when
started in the initial configuration qow, perform a computation that
eventually halts?"
At the bottom of the page, continuing to the next page, is a formal
definition of the solution of the halting problem, which Linz defines
as a Turing machine.
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
There is no "embedded_H" in Linz's definition.
<Linz text>
From H' we construct another Turing machine Ĥ.
That is later in the text, not in the definition 12.1, so irrelevant
to this discussion.
On 10/7/2026 5:40 AM, Mikko wrote:
On 02/10/2026 15:28, olcott wrote:
On 10/1/2026 10:05 PM, dart200 wrote:
On 10/1/26 5:28 PM, Chris M. Thomasson wrote:The key mistake of the halting theorem is that
On 10/1/2026 3:54 PM, dart200 wrote:
[...]
Are you saying that the halting problem is not solvable? If so, so
what?
it is solvable for an enumerable set of machines that includes all
possible output sequences, it is not solvable for all possible machines >>>
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()
No, it isn't. The halting problem says nothing about "DD()" or "main()".
The halting problem asks "How can one determine whether a computation
halts?"
Here is the same thing from Linz where H and Ĥ.embedded_H are
also based on UTM simulation of their inputs.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
*Keeps repeating unless aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
On 10/7/2026 5:40 AM, Mikko wrote:
On 02/10/2026 15:28, olcott wrote:
On 10/1/2026 10:05 PM, dart200 wrote:
On 10/1/26 5:28 PM, Chris M. Thomasson wrote:The key mistake of the halting theorem is that
On 10/1/2026 3:54 PM, dart200 wrote:
[...]
Are you saying that the halting problem is not solvable? If so, so
what?
it is solvable for an enumerable set of machines that includes all
possible output sequences, it is not solvable for all possible machines >>>
it requires a halt decider to report on the behavior
of the direct execution of DD() from main()
No, it isn't. The halting problem says nothing about "DD()" or "main()".
The halting problem asks "How can one determine whether a computation
halts?"
Here is the same thing from Linz where H and Ĥ.embedded_H are
also based on UTM simulation of their inputs.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,142 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 93:13:00 |
| Calls: | 14,704 |
| Calls today: | 2 |
| Files: | 186,497 |
| D/L today: |
2,377 files (788M bytes) |
| Messages: | 2,551,657 |