"It is sufficient for an SHD to DETECT infinite recursion without havingto SIMULATE it."
"If a problem permits infinite behavior in its formulation, it permitsinfinite analysis of that behavior in its decidability scope."
Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion =========================================================================
Overview:
---------
Flibble distinguishes between detecting infinite recursion and simulating
it. His argument is that a Simulating Halt Decider (SHD) does not need to perform unbounded execution to reach a decision—it only needs to *detect* unbounded behavior structurally. This refinement aligns with the demands placed on any decider: that it halt in finite time.
Key Statement:
--------------
"It is sufficient for an SHD to DETECT infinite recursion without havingto SIMULATE it."
Implications:
-------------
- SHDs must not rely on runtime behavior to conclude non-halting.
- Instead, SHDs should be built to identify infinite loops *structurally* (e.g., static analysis, recursion without base case, etc.).
Relation to Flibble's Law:
--------------------------
"If a problem permits infinite behavior in its formulation, it permitsinfinite analysis of that behavior in its decidability scope."
This law supports the claim that analyzing infinite behavior (in
principle) is necessary when such behavior is permitted. It doesn't mean running forever; it means using tools that can *infer* infinite behavior within a finite decision process.
Theoretical Soundness:
----------------------
- Aligns with static analysis and type theory approaches.
- Matches how total languages and proof assistants handle recursion (e.g., Agda, Coq).
- Respects the requirement that deciders halt in finite time.
Misconceptions Addressed:
-------------------------
- SHDs are not broken simulators—they are structural analyzers.
- Overflow or crash behavior is not failure—it’s evidence of an ill-formed
or semantically invalid input.
- Detection ≠ simulation; structure ≠ behavior.
Limitations:
------------
- SHDs remain partial—they cannot detect *all* forms of infinite recursion. - But this is not a flaw—it is a principled limitation, consistent with Flibble’s position that some inputs are semantically malformed and should be excluded from the decidable domain.
Conclusion:
-----------
Flibble sharpens his argument by clarifying that SHDs are not required to simulate infinite execution. They are expected to *detect* infinite
behavior structurally and respond in finite time. This keeps them within
the bounds of what a decider must be and strengthens the philosophical coherence of his redefinition of the Halting Problem.
On 5/20/25 3:10 PM, Mr Flibble wrote:
Conclusion: ----------- Flibble sharpens his argument by
clarifying that SHDs are not required to simulate infinite
execution. They are expected to *detect* infinite behavior
structurally and respond in finite time. This keeps them
within the bounds of what a decider must be and strengthens
the philosophical coherence of his redefinition of the
Halting Problem.
But you can't "redefine" the Halting Problem and then say you
have answered the Halting Problem.
On 5/20/2025 9:15 PM, Richard Damon wrote:
On 5/20/25 3:10 PM, Mr Flibble wrote:
Conclusion: ----------- Flibble sharpens his argument by
clarifying that SHDs are not required to simulate infinite
execution. They are expected to *detect* infinite behavior
structurally and respond in finite time. This keeps them
within the bounds of what a decider must be and
strengthens the philosophical coherence of his
redefinition of the Halting Problem.
But you can't "redefine" the Halting Problem and then say you
have answered the Halting Problem.
Do you mean like how ZFC resolved Russell's
Paradox thus converting "set theory" into "naive set theory"?
Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion =========================================================================
Overview:
---------
Flibble distinguishes between detecting infinite recursion and simulating
it. His argument is that a Simulating Halt Decider (SHD) does not need to perform unbounded execution to reach a decision—it only needs to *detect* unbounded behavior structurally. This refinement aligns with the demands placed on any decider: that it halt in finite time.
On 21/05/2025 03:15, Richard Damon wrote:
On 5/20/25 3:10 PM, Mr Flibble wrote:
<snip>
Conclusion: ----------- Flibble sharpens his argument by
clarifying that SHDs are not required to simulate infinite
execution. They are expected to *detect* infinite behavior
structurally and respond in finite time. This keeps them
within the bounds of what a decider must be and strengthens
the philosophical coherence of his redefinition of the
Halting Problem.
But you can't "redefine" the Halting Problem and then say you have
answered the Halting Problem.
Of course he can. In fact, life would be so much more pleasant if we
would all just let him redefine the Halting Problem as "Mr Olcott and
the psychotic penguin are both right because... well, *because*" and
confine our responses to 'that's rriigghhtt, you are so clever...' until
they tire of the Internet and turn back to their jelly and ice cream.
On 5/20/2025 9:15 PM, Richard Damon wrote:
On 5/20/25 3:10 PM, Mr Flibble wrote:
Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite
Recursion
========================================================================= >>>
Overview:
---------
Flibble distinguishes between detecting infinite recursion and
simulating
it. His argument is that a Simulating Halt Decider (SHD) does not
need to
perform unbounded execution to reach a decision—it only needs to
*detect*
unbounded behavior structurally. This refinement aligns with the demands >>> placed on any decider: that it halt in finite time.
Correct, it must be able to correctly determine that the hypothetical
complete simulation of the input program (which includes all it code,
and doesn't change in the hypthetical case) will not halt.
Key Statement:
--------------
"It is sufficient for an SHD to DETECT infinite recursion withoutto SIMULATE it."
having
Implications:
-------------
- SHDs must not rely on runtime behavior to conclude non-halting.
Wrong, because you can only detect infinte recursion if it is actually
there.
Remember, the input *IS* a program and doesn't change.
- Instead, SHDs should be built to identify infinite loops
*structurally*
(e.g., static analysis, recursion without base case, etc.).
Yes.
Relation to Flibble's Law:
--------------------------
"If a problem permits infinite behavior in its formulation, it permitsinfinite analysis of that behavior in its decidability scope."
FALSE. Violation of the rules of the system.
Decider MUST be finite in behavior.
This law supports the claim that analyzing infinite behavior (in
principle) is necessary when such behavior is permitted. It doesn't mean >>> running forever; it means using tools that can *infer* infinite behavior >>> within a finite decision process.
You can claim that it may NEED infinite analysis, you can not claim
the right to DO infinite analysis.
IF the only way to answer a problem is to use "infinite analysis",
then by definition, the problem is not decidable.
Theoretical Soundness:
----------------------
- Aligns with static analysis and type theory approaches.
No it doesn't.
- Matches how total languages and proof assistants handle recursion
(e.g.,
Agda, Coq).
Nope.
- Respects the requirement that deciders halt in finite time.
??? How can
Misconceptions Addressed:
-------------------------
- SHDs are not broken simulators—they are structural analyzers.
Ok, but they still need to answer about the actual behavior of the
input, as defined by the behavior when we execute the program it
represents.
- Overflow or crash behavior is not failure—it’s evidence of an ill- >>> formed
or semantically invalid input.
But since the "pathological input" isn't "ill-formed" that isn't an
out for the SHD.
- Detection ≠ simulation; structure ≠ behavior.
But correct answer is defined by actual behavior of direct exectution.
Limitations:
------------
- SHDs remain partial—they cannot detect *all* forms of infinite
recursion.
- But this is not a flaw—it is a principled limitation, consistent with >>> Flibble’s position that some inputs are semantically malformed and
should
be excluded from the decidable domain.
In other words, you ADMIT that the Halting Problem answer, that no
univerally correct Halt Deciders exist.
Conclusion:
-----------
Flibble sharpens his argument by clarifying that SHDs are not
required to
simulate infinite execution. They are expected to *detect* infinite
behavior structurally and respond in finite time. This keeps them within >>> the bounds of what a decider must be and strengthens the philosophical
coherence of his redefinition of the Halting Problem.
But you can't "redefine" the Halting Problem and then say you have
answered the Halting Problem.
Do you mean like how ZFC resolved Russell's
Paradox thus converting "set theory" into "naive set theory"?
On 5/21/2025 12:56 AM, Richard Heathfield wrote:
On 21/05/2025 06:23, olcott wrote:
Do you mean like how ZFC resolved Russell's
Paradox thus converting "set theory" into "naive set theory"?
No, because there is no paradox in the Halting Problem. A proof
by contradiction is not a paradox.
A self-contradictory input and a proof by contradiction
are not the same thing.
A proof by contradiction would
conclude that "this sentence is not true" is true because
it cannot be proved false.
ZFC shows how a whole way of examining a problem can be
tossed out as incorrect and replaced with a whole new way.
The HP proofs are based on defining a D that can
actually do the opposite of whatever value that H returns.
No such D can actually exist.
On 5/21/2025 11:09 AM, Richard Heathfield wrote:
That an algorithm for ascertaining whether an arbitrary program
with arbitrary input halts cannot actually exist is precisely
what the Halting Problem proves.
If you think that it can exist then prove that it
exists by encoding it in C.
On 5/21/2025 12:16 PM, Richard Heathfield wrote:
On 21/05/2025 17:51, olcott wrote:
On 5/21/2025 11:09 AM, Richard Heathfield wrote:
<snip>
That an algorithm for ascertaining whether an arbitrary
program with arbitrary input halts cannot actually exist is
precisely what the Halting Problem proves.
If you think that it can exist then prove that it
exists by encoding it in C.
It can't exist. The Halting Problem proves that it can't. I
said that already.
*PAY ATTENTION*
I am saying that a key element of the halting problem
proof cannot exist, thus the proof itself cannot exist.
Do you understand that a non-existent proof cannot
prove one damn thing?
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
Definition: a prime number is an integer >= 2 with no divisors >= 2
except itself.
Hypothesis: there is no largest prime number.
Proof:
Assume that a largest prime number Pn exists.
Itemise all the prime numbers from P1(=2) up to Pn :
P1 P2 P3 ... Pn
Insert x symbols all the way along.
P1 x P2 x P3 ... x Pn
Add 1.
The number thus calculated is not divisible by any prime in our list
(there being a remainder of 1 in each case), so the number calculated
is (a) prime, and (b) larger than Pn. Thus Pn is not the largest
prime. This contradicts the assumption made at the beginning, which
must therefore be false. Proof by contradiction.
You've made a mistake in an otherwise valid proof.
The number
(P1 x P2 x P3 ... x Pn) + 1 *either* is prime *or* is composite
and a multiple of some prime number larger than Pn.
For example, (2*3*5*7*11*13)+1 is 30031, which is 59*509.
Show how to define a D that actually does the opposite
of what its termination analyzer reports.
On 5/21/2025 12:56 AM, Richard Heathfield wrote:
On 21/05/2025 06:23, olcott wrote:
On 5/20/2025 9:15 PM, Richard Damon wrote:
On 5/20/25 3:10 PM, Mr Flibble wrote:
<snip>
Conclusion: ----------- Flibble sharpens his argument by
clarifying that SHDs are not required to simulate infinite
execution. They are expected to *detect* infinite behavior
structurally and respond in finite time. This keeps them
within the bounds of what a decider must be and
strengthens the philosophical coherence of his
redefinition of the Halting Problem.
But you can't "redefine" the Halting Problem and then say you have
answered the Halting Problem.
Do you mean like how ZFC resolved Russell's
Paradox thus converting "set theory" into "naive set theory"?
No, because there is no paradox in the Halting Problem. A proof by
contradiction is not a paradox.
A self-contradictory input and a proof by contradiction
are not the same thing. A proof by contradiction would
conclude that "this sentence is not true" is true because
it cannot be proved false.
ZFC shows how a whole way of examining a problem can be
tossed out as incorrect and replaced with a whole new way.
The HP proofs are based on defining a D that can
actually do the opposite of whatever value that H returns.
No such D can actually exist.
A better parallel would be Cantor's proof that there are uncountably
many real numbers, or Euclid's proof that there is no largest prime.
Both of these proofs make a single assumption and then derive a
contradiction, thus showing that the assumption must be false. No
paradoxes need apply.
In the Halting Problem's case, the assumption is that a UNIVERSAL
algorithm exists for determining whether any arbitrary program halts
when applied to given arbitrary input. The argument derives a
contradiction showing the assumption to be false.
Likewise with Russell's Paradox it is assumed that there
can be a set of all sets that do not contain themselves as
members. This is "resolved" as nonsense.
Whatever you think your HHH determines, we know from Turing that it
doesn't determine it for arbitrary programs with arbitrary input. It
therefore has no bearing whatsoever on the Halting Problem.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH DOES NOT HALT.
On 5/21/2025 2:06 PM, Richard Heathfield wrote:
On 21/05/2025 19:48, olcott wrote:
<snip>
Show how to define a D that actually does the opposite
of what its termination analyzer reports.
The whole point of the proof is that no algorithm can define a
universal halt decider.
I have NEVER been talking about that.
I have only been talking about the ACTUAL
conventional proof of the halting problem.
On 5/21/2025 3:13 PM, Richard Heathfield wrote:
On 21/05/2025 20:28, olcott wrote:
I have only been talking about the ACTUAL
conventional proof of the halting problem.
The ACTUAL conventional proof of the Halting Problem goes
something like this:
1) assume that it is possible to devise an algorithm that can
determine in finitely many steps ascertain whether an arbitrary
program applied to arbitrary data does or does not stop.
2) given such an algorithm, imagine incorporating it into a
program that ascertains whether a supplied program with
supplied data halts, loops if it does, and halts if it doesn't.
This step is impossible.
It only seemed possible
because no one ever
tried to completely encode every detail.
This screwy mistake came about
because fools thought
that a halt decider H is supposed to report on the behavior
of the program that itself is contained within rather
than the behavior that its actual input actually specifies.
int main()
{
DDD(); // No HHH can report on the behavior of its caller.
}
On 5/21/2025 4:21 PM, Richard Heathfield wrote:
On 21/05/2025 21:28, olcott wrote:
no one ever
tried to completely encode every detail.
Why would they? One would have to be pretty stupid to try.
Show an actual input to HHH that actually does
the opposite of whatever value that HHH returns.
On 5/21/2025 12:56 AM, Richard Heathfield wrote:
On 21/05/2025 06:23, olcott wrote:
On 5/20/2025 9:15 PM, Richard Damon wrote:
On 5/20/25 3:10 PM, Mr Flibble wrote:
<snip>
Conclusion: ----------- Flibble sharpens his argument by
clarifying that SHDs are not required to simulate infinite
execution. They are expected to *detect* infinite behavior
structurally and respond in finite time. This keeps them
within the bounds of what a decider must be and
strengthens the philosophical coherence of his
redefinition of the Halting Problem.
But you can't "redefine" the Halting Problem and then say you have
answered the Halting Problem.
Do you mean like how ZFC resolved Russell's
Paradox thus converting "set theory" into "naive set theory"?
No, because there is no paradox in the Halting Problem. A proof by
contradiction is not a paradox.
A self-contradictory input and a proof by contradiction
are not the same thing. A proof by contradiction would
conclude that "this sentence is not true" is true because
it cannot be proved false.
ZFC shows how a whole way of examining a problem can be
tossed out as incorrect and replaced with a whole new way.
The HP proofs are based on defining a D that can
actually do the opposite of whatever value that H returns.
No such D can actually exist.
A better parallel would be Cantor's proof that there are uncountably
many real numbers, or Euclid's proof that there is no largest prime.
Both of these proofs make a single assumption and then derive a
contradiction, thus showing that the assumption must be false. No
paradoxes need apply.
In the Halting Problem's case, the assumption is that a UNIVERSAL
algorithm exists for determining whether any arbitrary program halts
when applied to given arbitrary input. The argument derives a
contradiction showing the assumption to be false.
Likewise with Russell's Paradox it is assumed that there
can be a set of all sets that do not contain themselves as
members. This is "resolved" as nonsense.
Whatever you think your HHH determines, we know from Turing that it
doesn't determine it for arbitrary programs with arbitrary input. It
therefore has no bearing whatsoever on the Halting Problem.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH DOES NOT HALT.
On 5/21/25 11:54 AM, olcott wrote:
A self-contradictory input and a proof by contradiction
are not the same thing. A proof by contradiction would
conclude that "this sentence is not true" is true because
it cannot be proved false.
The input is NOT "self-contradictory".
The proof by contradiction is based on, If an H existed that got
the right answer, the answer it gives would be wrong.
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
On 21/05/2025 23:34, olcott wrote:
On 5/21/2025 4:21 PM, Richard Heathfield wrote:
On 21/05/2025 21:28, olcott wrote:
<snip>
no one ever
tried to completely encode every detail.
Why would they? One would have to be pretty stupid to try.
<snip>
Show an actual input to HHH that actually does
the opposite of whatever value that HHH returns.
You don't listen good, do you?
Turing proved that what you're asking is impossible.
That is not what he proved.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good
luck with that.
Not necessarily.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
-- that doesn't imply
that he or anyone else would be able to write one.
I've never been entirely clear on what olcott is claiming.
[...] He has rarely, if ever, stated his claims clearly enough
for anyone to be sure what he's claiming. Of course I could
have missed something, since I've read less than 1% of what he
writes.
But if you took everything he's posted here and combined it into
a single text file, I'll bet it would compress *really* well.
On 5/22/2025 1:52 AM, joes wrote:
Am Wed, 21 May 2025 18:14:42 -0500 schrieb olcott:
All of the proofs ASSUME that there is an input D that
can ACTUALLY DO the opposite of whatever value that H
returns making it impossible for H to decide D.
No, the proof assumes there is a *decider* and then shows
exactly *how* to construct a counterexample.
Yet no one ever bothers to notice that
this counter-example input cannot possibly
actually do the opposite of whatever value
that its decider returns.
*The proof by contradiction CANNOT EVEN BE CREATED*
I dared you to define an input D to termination
analyzer H that actually does the opposite of
whatever value that H returns AND YOU FAILED !!!
ARE YOU IGNORANT OR DISHONEST?
You don't have a clue:
https://en.wikipedia.org/wiki/Halting_problem#Proof_concept
On 5/22/2025 11:59 AM, Richard Heathfield wrote:
On 22/05/2025 17:45, olcott wrote:
<snip>
You don't have a clue:
Righty-ho.
https://en.wikipedia.org/wiki/Halting_problem#Proof_concept
Is it this bit you mean?
There are programs (interpreters) that simulate the execution
of whatever source code they are given. Such programs can
demonstrate that a program does halt if this is the case: the
interpreter itself will eventually halt its simulation, which
shows that the original program halted. However, an interpreter
will not halt if its input program does not halt, so this
approach cannot solve the halting problem as stated; it does
not successfully answer "does not halt" for programs that do
not halt.
*The part that the actual link links to*
In other words you are too scatterbrained to keep
focused on a single point until closure is achieved.
On 5/22/2025 1:33 PM, Richard Heathfield wrote:
On 22/05/2025 19:16, olcott wrote:
<snip>
In other words you are too scatterbrained to keep
focused on a single point until closure is achieved.
Closure happened in 1936.
*CLOSURE ON THIS POINT HAS NEVER BEEN ACHIEVED*
When you try to define an input D to simulating termination
analyzer H that actually does the opposite of whatever value
that H returns you find that this
KEY ELEMENT OF THE CONVENTIONAL HALTING
PROBLEM PROOFS CANNOT POSSIBLY EXIST.
On 5/22/2025 1:49 PM, Richard Heathfield wrote:
On 22/05/2025 19:46, olcott wrote:
KEY ELEMENT OF THE CONVENTIONAL HALTING
PROBLEM PROOFS CANNOT POSSIBLY EXIST.
What it proves is that the universal termination analysis
program cannot exist.
Show HOW it proves that
and I will point out your mistake.
(You don't know how, you are only a parrot)
On 5/22/2025 1:52 AM, joes wrote:
Am Wed, 21 May 2025 18:14:42 -0500 schrieb olcott:
All of the proofs ASSUME that there is an input D that can ACTUALLY DONo, the proof assumes there is a *decider* and then shows exactly *how*
the opposite of whatever value that H returns making it impossible for H >>> to decide D.
to construct a counterexample.
Yet no one ever bothers to notice that
this counter-example input cannot possibly
actually do the opposite of whatever value
that its decider returns.
An Internet crank claims to have refuted Linz HP proof byThat's pretty much what I gleaned, of course, but if there's one
creating a Halt Decider that CORRECTLY decides its own
"impossible input"!
On 5/22/2025 1:33 PM, Richard Heathfield wrote:
On 22/05/2025 19:16, olcott wrote:
<snip>
In other words you are too scatterbrained to keep
focused on a single point until closure is achieved.
Closure happened in 1936.
*CLOSURE ON THIS POINT HAS NEVER BEEN ACHIEVED*
When you try to define an input D to simulating termination
analyzer H that actually does the opposite of whatever value
that H returns you find that this
KEY ELEMENT OF THE CONVENTIONAL HALTING
PROBLEM PROOFS CANNOT POSSIBLY EXIST.
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can >>>>> correctly report for any program and any input whether it halts. Good >>>>> luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start
to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a
Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.) >>
Mike.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
On 5/22/2025 1:52 AM, joes wrote:
Am Wed, 21 May 2025 18:14:42 -0500 schrieb olcott:
All of the proofs ASSUME that there is an input D that can ACTUALLY DONo, the proof assumes there is a *decider* and then shows exactly *how*
the opposite of whatever value that H returns making it impossible for H >>> to decide D.
to construct a counterexample.
Yet no one ever bothers to notice that
this counter-example input cannot possibly
actually do the opposite of whatever value
that its decider returns.
On 5/21/2025 2:37 PM, Mr Flibble wrote:
On Wed, 21 May 2025 21:32:49 +0200, Fred. Zwarts wrote:
Op 21.mei.2025 om 17:54 schreef olcott:
On 5/21/2025 12:56 AM, Richard Heathfield wrote:Verifiable counter-factual.
On 21/05/2025 06:23, olcott wrote:A self-contradictory input and a proof by contradiction are not the
On 5/20/2025 9:15 PM, Richard Damon wrote:
On 5/20/25 3:10 PM, Mr Flibble wrote:
<snip>
Conclusion: ----------- Flibble sharpens his argument by clarifying >>>>>>>> that SHDs are not required to simulate infinite execution. They are >>>>>>>> expected to *detect* infinite behavior structurally and respond in >>>>>>>> finite time. This keeps them within the bounds of what a decider >>>>>>>> must be and strengthens the philosophical coherence of his
redefinition of the Halting Problem.
But you can't "redefine" the Halting Problem and then say you have >>>>>>> answered the Halting Problem.
Do you mean like how ZFC resolved Russell's Paradox thus converting >>>>>> "set theory" into "naive set theory"?
No, because there is no paradox in the Halting Problem. A proof by
contradiction is not a paradox.
same thing. A proof by contradiction would conclude that "this sentence >>>> is not true" is true because it cannot be proved false.
ZFC shows how a whole way of examining a problem can be tossed out as
incorrect and replaced with a whole new way.
The HP proofs are based on defining a D that can actually do the
opposite of whatever value that H returns.
No such D can actually exist.
A better parallel would be Cantor's proof that there are uncountably >>>>> many real numbers, or Euclid's proof that there is no largest prime. >>>>> Both of these proofs make a single assumption and then derive aLikewise with Russell's Paradox it is assumed that there can be a set
contradiction, thus showing that the assumption must be false. No
paradoxes need apply.
In the Halting Problem's case, the assumption is that a UNIVERSAL
algorithm exists for determining whether any arbitrary program halts >>>>> when applied to given arbitrary input. The argument derives a
contradiction showing the assumption to be false.
of all sets that do not contain themselves as members. This is
"resolved" as nonsense.
Whatever you think your HHH determines, we know from Turing that itvoid DDD()
doesn't determine it for arbitrary programs with arbitrary input. It >>>>> therefore has no bearing whatsoever on the Halting Problem.
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH DOES NOT HALT.
The simulation of DDD does not reach a natural end only because HHH
prevents it to halt by a premature abort.
Due this premature abort HHH misses the part of the input that specifies >>> the conditional abort in Halt7.c, which specifies that the program
halts. If a simulator would not abort this input, it would reach the
natural end of the program. Proven by direct execution and world-class
simulators. But HHH has a bug, which makes that it aborts before it can
see that the input halts, only because its programmer dreamed of an
infinite recursion, where there is only a finite recursion.
Come out of rebuttal mode, which makes that you do not pay enough
attention to this logic, but reject it immediately when it disturbs your >>> dreams, after which you only repeat the clueless claims.
You are making the classic mistake of conflating the decider halting with
the program being analysed halting.
/Flibble
Its even worse than that.
HHH is correct to abort its simulation of DDD even when
we include HHH as an aspect of its input DDD thus conflating
HHH and DDD together.
<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
Unless DDD aborts its simulated DDD even HHH()
(DDD and HHH conflated together)
never stops running.
On 5/21/2025 2:32 PM, Fred. Zwarts wrote:
Op 21.mei.2025 om 17:54 schreef olcott:
On 5/21/2025 12:56 AM, Richard Heathfield wrote:
On 21/05/2025 06:23, olcott wrote:
On 5/20/2025 9:15 PM, Richard Damon wrote:
On 5/20/25 3:10 PM, Mr Flibble wrote:
<snip>
Conclusion: ----------- Flibble sharpens his argument by
clarifying that SHDs are not required to simulate infinite
execution. They are expected to *detect* infinite behavior
structurally and respond in finite time. This keeps them
within the bounds of what a decider must be and
strengthens the philosophical coherence of his
redefinition of the Halting Problem.
But you can't "redefine" the Halting Problem and then say you have >>>>>> answered the Halting Problem.
Do you mean like how ZFC resolved Russell's
Paradox thus converting "set theory" into "naive set theory"?
No, because there is no paradox in the Halting Problem. A proof by
contradiction is not a paradox.
A self-contradictory input and a proof by contradiction
are not the same thing. A proof by contradiction would
conclude that "this sentence is not true" is true because
it cannot be proved false.
ZFC shows how a whole way of examining a problem can be
tossed out as incorrect and replaced with a whole new way.
The HP proofs are based on defining a D that can
actually do the opposite of whatever value that H returns.
No such D can actually exist.
A better parallel would be Cantor's proof that there are uncountably
many real numbers, or Euclid's proof that there is no largest prime.
Both of these proofs make a single assumption and then derive a
contradiction, thus showing that the assumption must be false. No
paradoxes need apply.
In the Halting Problem's case, the assumption is that a UNIVERSAL
algorithm exists for determining whether any arbitrary program halts
when applied to given arbitrary input. The argument derives a
contradiction showing the assumption to be false.
Likewise with Russell's Paradox it is assumed that there
can be a set of all sets that do not contain themselves as
members. This is "resolved" as nonsense.
Whatever you think your HHH determines, we know from Turing that it
doesn't determine it for arbitrary programs with arbitrary input. It
therefore has no bearing whatsoever on the Halting Problem.
void DDD()
{
HHH(DDD);
return;
}
DDD correctly simulated by HHH DOES NOT HALT.
Verifiable counter-factual.
The simulation of DDD does not reach a natural end only because HHH
prevents it to halt by a premature abort.
That is not true yet not a damned lie.
You are merely incompetent at software engineering.
Richard Heathfield <rjh@cpax.org.uk> writes:
On 21/05/2025 18:47, olcott wrote:...
*PAY ATTENTION*
I am saying that a key element of the halting problem
proof cannot exist, thus the proof itself cannot exist.
Yes, it can, and it does.
You'd think that at some point in decades he's wasted on this he might
have considered looking at the proofs that are not by contradiction.
I've repeatedly suggested looking at Radó's Busy Bee problem and proof.
Watch.
Definition: a prime number is an integer >= 2 with no divisors >= 2 except >> itself.
Hypothesis: there is no largest prime number.
Proof:
Assume that a largest prime number Pn exists.
Itemise all the prime numbers from P1(=2) up to Pn :
P1 P2 P3 ... Pn
Insert x symbols all the way along.
P1 x P2 x P3 ... x Pn
Add 1.
The number thus calculated is not divisible by any prime in our list (there >> being a remainder of 1 in each case), so the number calculated is (a)
prime, and (b) larger than Pn. Thus Pn is not the largest prime. This
contradicts the assumption made at the beginning, which must therefore be
false. Proof by contradiction.
The proof that no largest prime exists despite its assumption that such a
prime /does/ exist - an assumption that turns out to be false.
Interestingly (and not, I think, coincidentally) Euclid's proof is not a proof by contradiction. It shows (by case analysis) that any finite
list of primes is incomplete. There is (in the way Euclid does it) no
need to assume anything (other than some basic axioms).
The same strategy can be used for the halting theorem. The more direct
proof essentially shows that the infinite list of Turing machines (there
is only one, once we agree a numbering) does not include a halt decider
(just like it does not include uncountably many other deciders that the cranks are never interested in).
PO seems to like talking to you so you might consider avoiding any
arguments about contradictions by providing an outline of the direct
proof instead.
I've lost count of the times when the proof by contradiction leads
students astray. Even if they don't think it's invalid, every year one
has to counter the idea that all the decider has to do is "spot the
tricky input" and the decider will work on everything else.
I'm finding it hard to believe that you can really be this stupid. Perhaps >> you just get off yanking people's chains.
Hmm... Don't forget Hanlon's razor. As for data points, PO has
published a website whose purpose is to "bring new scripture to the
world" and he has claimed, in a court of law, to be God.
Incidentally, there is even a modern proof by construction of the
infinitude of the primes. The idea being that since n and (n+1) have no prime factors in common, n(n+1) has more distinct prime factors that n.
This gives a chain of ever larger sets of primes: the unique prime
factors of 2x3, 6x7, 42x43 and so on.
On 5/23/2025 8:00 AM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:Of course not. But I'm just reflecting. He seemed to think that my
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that >>>>>> can
correctly report for any program and any input whether it halts. Good >>>>>> luck with that.
Not necessarily.
inability to write the kind of program Turing envisaged (an inability
that I readily concede) is evidence for his argument. Well, what's
sauce
for the goose is sauce for the gander.
Even if olcott had refuted the proofs of theAnd we both know what we both think of that idea.
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
-- that doesn't implyIndeed.
that he or anyone else would be able to write one.
I've never been entirely clear on what olcott is claiming.Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter
how clearly he explains it to me my eyes glaze over and I start to
snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a >>> Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up
with.)
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it
in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
<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
Or perhaps you prefer this explanation from 2023:
| (1) A return value of 1 from H(D,D) means the input to H(D,D) has
halted
|
| (2) A return value of 0 from H(D,D) has been redefined to mean
| (a) D does not halt
| (b) D has been defined to do the opposite of whatever Boolean value
| that H returns.
All very clear. Of course (2)(b) is undeciable in general.
(2)(b) is not sufficiently precise.
INPUT D to simulating termination analyzer H
has been defined to do the opposite of whatever
Boolean value that H returns.
*Cannot possibly be defined*
int main()
{
DD(); // The HHH that DD calls cannot possibly report
} // on the behavior of its caller.
// That is just NOT the way that computations work.
On 5/23/2025 1:37 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it
in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
It is a tautology that a dozen people here
have been trying to get away with denying
for two and one half years.
<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 D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
On 5/23/2025 2:17 AM, Mikko wrote:
On 2025-05-23 05:25:30 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser
that can
correctly report for any program and any input whether it halts. >>>>>>> Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an
inability that I readily concede) is evidence for his argument.
Well, what's sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I
start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made
the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a >>>> Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up
with.)
Mike.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
That is not a valid sentence: there is an subordinate clause and two
main clauses but nothing that combines the main clauses to an overall
meaning.
Is is not supposed to be an English sentence nitwit.
It is a simplification of the Linz definition of Ĥ.
On the top of page 3:
https://www.liarparadox.org/Linz_Proof.pdf
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
On 5/23/2025 2:18 AM, Mikko wrote:
On 2025-05-22 15:37:31 +0000, olcott said:
On 5/22/2025 1:52 AM, joes wrote:
Am Wed, 21 May 2025 18:14:42 -0500 schrieb olcott:
All of the proofs ASSUME that there is an input D that can ACTUALLY DO >>>>> the opposite of whatever value that H returns making it impossibleNo, the proof assumes there is a *decider* and then shows exactly *how* >>>> to construct a counterexample.
for H
to decide D.
Yet no one ever bothers to notice that
this counter-example input cannot possibly
actually do the opposite of whatever value
that its decider returns.
It really is hard to notice someting that is very obviously false.
You must look at it 100-fold more closely than anyone else ever has.
int main()
{
DD(); // How does the HHH that DD calls report on the
} // behavior of its caller?
On 5/23/2025 2:30 AM, Mikko wrote:
On 2025-05-22 18:46:10 +0000, olcott said:
On 5/22/2025 1:33 PM, Richard Heathfield wrote:
On 22/05/2025 19:16, olcott wrote:
<snip>
In other words you are too scatterbrained to keep
focused on a single point until closure is achieved.
Closure happened in 1936.
*CLOSURE ON THIS POINT HAS NEVER BEEN ACHIEVED*
When you try to define an input D to simulating termination
analyzer H that actually does the opposite of whatever value
that H returns you find that this
KEY ELEMENT OF THE CONVENTIONAL HALTING
PROBLEM PROOFS CANNOT POSSIBLY EXIST.
Unless H is a counter-example to the Church-Turing thesis it
is possible to construct such D and prove that H is not a
halting decider.
When you do that within the abstraction of Turing Machines
people get confused and conflate the computation that
the halt decider is contained within as its own input.
*This mistake is more obvious when it is made concrete*
int main()
{
DD(); // How does the HHH that DD calls report
} // on the behavior of its caller?
Liar
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
On 5/23/2025 1:37 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it
in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
It is a tautology that a dozen people here
have been trying to get away with denying
for two and one half years.
<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 D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD emulated by HHH according to the semantics of the x86
language cannot possibly reach its own "ret" instruction.
A dozen people here have lied about that for 2.5 years.
This kind of determination can be made in specific cases (but of
course not in general). A simple program like `int main(void)
{ while (1); }` is non-halting. If I run it, it will never halt
unless I force it to halt, e.g. by typing Control-C or pulling the
power plug.
(I'm assuming that "when-so-ever" means the same as "when".)
[...]
On 5/23/2025 6:25 PM, Ben Bacarisse wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it >>>> in words:
| When-so-ever a halt decider correctly determines that its input would >>>> | never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
It would be a tautology but for the "unless..." part. It does not make
the determination that it does not halt. It determines that it would
not halt were it not for the fact that the decider (a simulation) in
fact halts it.
Still a tautology.
When the simulated input specifies a non-halting sequence
of configurations as proven by the fact that DD simulated
by HHH would never stop running unless aborted,
THIS TOO IS A TAUTOLOGY.
Fools here want to ignore the that the input to HHH(DD)
specifies a non-halting sequence of configurations and
instead have HHH report on some other basis.
int main()
{
DD(); // HHH cannot report on the behavior of its caller
} // Thus HHH cannot report on the behavior of the
// direct execution of DD();
Most of my reviewers are screwball trolls not giving
a rat's ass for truth.
On 5/23/2025 7:36 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said >>>>> this explicitly (as I have posted before) but he has also explained it >>>>> in words:
| When-so-ever a halt decider correctly determines that its input
would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
It would be a tautology but for the "unless..." part. It does not make >>> the determination that it does not halt. It determines that it would
not halt were it not for the fact that the decider (a simulation) in
fact halts it.
Right, so the computation itself is non-halting. The mythical
"halt decider" is a simulator that, I suppose, can either faithfully
execute the computation (which will take forever if it's non-halting)
*or* partially execute it and stop executing it at some arbitrary
point. (The latter is of course not a correct full emulation of
the computation.) The "forced to halt" step is not part of the
computation.
`int main(void) { while (1); }` is non-halting, at least in the C
abstract machine. The fact that I can kill it by typing Control-C or
pulling the power plug doesn't change that. If I don't immediately
notice the obvious, I can simulate its execution, letting it iterate
a few times, until I realize that it's never going to halt. At that
point I can interrupt my simulation and correctly report that the
program does not halt (something I can do for this program, but not for
all programs).
If you don't assume that this "halt decider" is the impossible
thing that olcott claims it is, but rather is a program that can
simulate another program's execution and report one of "halts",
"does not halt", or "I don't know", it seems to me that olcott's
statement is true and unremarkable (though a little convoluted).
It does not of course refute the validity of the existing proofs
that the Halting Problem is unsolvable.
I'm trying to analyze the statement by itself, ignoring the context
of the years of nonsense olcott has posted.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
When DDD is emulated by HHH according to the rules
of the x86 language then DDD cycles through its first
four instructions until HHH aborts its simulation.
On 5/14/2025 7:36 PM, Mike Terry wrote:
In the case of his HHH/DD, the simulated input
(DD) /does/ stop running if simulated far enough,
Likewise all infinite loops stop running when
you can wait until the heat death of the universe.
On 5/23/2025 2:01 PM, Richard Damon wrote:
On 5/23/25 12:39 PM, olcott wrote:
On 5/23/2025 2:18 AM, Mikko wrote:
On 2025-05-22 15:37:31 +0000, olcott said:
On 5/22/2025 1:52 AM, joes wrote:
Am Wed, 21 May 2025 18:14:42 -0500 schrieb olcott:
All of the proofs ASSUME that there is an input D that canNo, the proof assumes there is a *decider* and then shows exactly
ACTUALLY DO
the opposite of whatever value that H returns making it
impossible for H
to decide D.
*how*
to construct a counterexample.
Yet no one ever bothers to notice that
this counter-example input cannot possibly
actually do the opposite of whatever value
that its decider returns.
It really is hard to notice someting that is very obviously false.
You must look at it 100-fold more closely than anyone else ever has.
int main()
{
DD(); // How does the HHH that DD calls report on the
} // behavior of its caller?
Wrong, as explained in the other message.
Liar
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
On 5/23/2025 7:57 PM, dbush wrote:
On 5/23/2025 8:54 PM, olcott wrote:
On 5/23/2025 7:44 PM, dbush wrote:
On 5/23/2025 8:08 PM, Mike Terry wrote:
I suppose Ben quoted PO saying this, because PO /uses/ it to
justify that a particular /halting/ computation will never halt,
PO's HHH simulates DDD (which halts) but before DDD halts it spots
a pattern in the simulation, and announces non-halting. "Eh?" I
hear you say! PO claims HHH has "correctly determined that DDD
would never halt" and so is correct to decide non-halting. His
"proof" that it is right to decide non-halting is his "when-so-
ever.." quote, which broadly matches the Sipser quote.
So the problem is not so much the "when-so-ever.." words themselves
[or the words of Sipser's quote], but understanding how PO is so
thoroughly misinterpreting/misapplying them. How can PO believe
HHH has "correctly determined the DDD will never halt" when DDD
demonstrably halts?
PO is working in a different model than the rest of us, though he
doesn't seem to understand that.
To him, when function H is deciding on something, the implementation
of H is allowed to vary. This results in functions that call H to
vary as a result. To him, "DDD" is the same computation *regardless
of the implementation of HHH*, in cases where HHH is simulating DDD.
This is essentially the mapping he's operating with:
-----------------
For a function X with input Y and a function H which simulates X:
POH(H,X,Y)==1 if and only if there exists an implementation of H
that can simulate X(Y) to completion
POH(H,X,Y)==0 if and only if there does not exist an implementation
of H that can simulate X(Y) to completion
----------------
And a "decider" in his case maps the following subset:
----------------
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y)
----------------
So given his rules, HHH1(DDD) is deciding on a algorithm while
HHH(DDD) is deciding on a C function whose subfunctions vary.
This of course has nothing to do with the halting problem but he
doesn't get this. After having spent 22 years on this, he'll come
up with any crazy justification to avoid admitting to himself that
he misunderstood the problem all this time. He once said (and I
don't recall the exact wording) that "the directly executed D
doesn't halt even though it appears to".
The problem is that people here are too stupid
to notice that HHH cannot report on the behavior
of its caller.
int min()
{
DD(); // HHH cannot report on the behavior of its caller.
}
What about this?
If you can't stay exactly on topic I am going to ignore
everything that you say.
HHH cannot report on the behavior of its caller AKA the
direct execution of DD().
On 5/23/2025 2:17 AM, Mikko wrote:
On 2025-05-23 05:25:30 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can >>>>>>> correctly report for any program and any input whether it halts. Good >>>>>>> luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my
inability to write the kind of program Turing envisaged (an inability >>>>> that I readily concede) is evidence for his argument. Well, what's
sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved
that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no
matter how clearly he explains it to me my eyes glaze over and I start >>>>> to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the
front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a >>>> Halt Decider that CORRECTLY decides its own "impossible input"!
The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
That is not a valid sentence: there is an subordinate clause and two
main clauses but nothing that combines the main clauses to an overall
meaning.
Is is not supposed to be an English sentence nitwit.
It is a simplification of the Linz definition of Ĥ.
On 5/23/2025 7:08 PM, Mike Terry wrote:
On 23/05/2025 19:37, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it >>>> in words:
| When-so-ever a halt decider correctly determines that its input would >>>> | never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said
Sipser would be interpreting the oft-quoted "Sipser quote". I don't
think you've missed anything particularly.
I suppose Ben quoted PO saying this, because PO /uses/ it to justify
that a particular /halting/ computation will never halt, PO's HHH
simulates DDD (which halts) but before DDD halts it spots a pattern in
the simulation, and announces non-halting.
In other words you expect that the HHH that DD calls
to report on the behavior of its caller?
How the f-ck can it do that?
On 5/23/2025 9:41 PM, Mike Terry wrote:
On 24/05/2025 01:26, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/05/2025 19:37, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is theHmm. I don't read that the way you do. Did I miss something?
correct halting decision for some halting computations. He has said >>>>>> this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its input
would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said
Sipser
would be interpreting the oft-quoted "Sipser quote". I don't think
you've
missed anything particularly.
Maybe it makes less sense out of the context it was posted in. This was >>> when he was being less obtuse. The computation in question only halts
because it is halted by the decider on which it is built. It is a
halting computation, but according to PO it can reported as not halting
because of what would happen if it were not halted by the decider from
which it is derived.
"The computation in question only halts because it is halted by the
decider on which it is built."
That is presumably you speaking in PO's voice, but my first reading
was as you saying it!
Of course, the computation in question [DDD(DDD)] is at no point
"halted" by anything, and halts quite happily all on by itself!
That is not true and you may not know it.
and you didn't even say it correctly.
DDD() takes no params.
int main()
{
DDD(); // cannot possibly stop running unless
} // HHH(DDD) aborts its simulation
Subsequent wordings have all been about hiding this. Just prior to this >>> wording was the even more explicit claim that non-halting is correct
because of what "would happen if line 15 were commented out". It's
always been about what would be the correct decision were the
computation not what it actually is.
Yes, current posters are right on top of that, calling it out as
"changing the input". I'm not sure PO realises he is changing the
input, and if he does, whether he understands /why/ that is completely
out of order.
<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
Doesn't actually change the input.
Is the term "hypothetical" OVER-YOUR-HEAD?
D correctly reports on what the behavior would be if a
*HYPOTHETICAL H* never aborted the simulation of its input.
THAT IS THE BEHAVIOR THAT THIS INPUT SPECIFIES.
PO has recently started talking about what happens when we
hypothetically "change the HHH/DDD input /pair/ " so that makes me
think he does now explicitly realise that's what's going on, but not
why it's a mistake.
Everyone here including you believes that HHH
is not allowed to report on the actual behavior
that its input actually specifies and instead
MUST report on the behavior of its caller.
int main()
{
DDD(); // HHH cannot report on the behavior of its caller.
}
As ever, pointing it out to PO, however explicitly and clearly, has no
effect on what PO believes.
Mike.
On 5/23/2025 10:55 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:void DDD()
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/05/2025 19:37, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is theHmm. I don't read that the way you do. Did I miss something?
correct halting decision for some halting computations. He has said >>>>>> this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its input
would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said
Sipser
would be interpreting the oft-quoted "Sipser quote". I don't think
you've
missed anything particularly.
Maybe it makes less sense out of the context it was posted in. This was >>> when he was being less obtuse. The computation in question only halts
because it is halted by the decider on which it is built. It is a
halting computation, but according to PO it can reported as not halting
because of what would happen if it were not halted by the decider from
which it is derived.
I think you're misreading it (or, if you prefer, I have yet to be
convinced that I'm misreading it).
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Call the "halt decider" H, and the input I. If you perform the
computation specified by I, it never halts. olcott's statement
is that if H correctly determines that I never halts (assume for
now that that's possible), then H can correctly report that I
never halts. This is true, tautological, and uninteresting.
There is *another* computation, I-simulated-by-H. This computation
may halt if H decides to halt it. But I-simulated-by-H is not I.
H's alleged job is to determine the halting status of I, not the
halting status of I-simulated-by-H.
{
HHH(DDD);
return;
}
Unless HHH aborts its simulation of DDD it never stops running.
I think you're saying that H *incorrectly* reports that
I-simulated-by-H never halts. My interpretation is that H
*correctly* reports that I never halts.
The above is based only on that isolated statement, without reference
to olcott's other claims. Moving on to the larger context:
If a general solution to the halting problem were possible (we
know it isn't), a simulating halt decider could be one possible
way to approach it. It is, I suppose, a tempting idea. You could
imagine a simulator that runs a program one step at a time, and
after each step, reports that it just halted if it has, or performs
some analysis that attempts to determine that it will never halt.
If it's able to make that determination, the simulator can halt
and correctly report that the simulated program never halts.
If the program runs on a machine with a finite number of states, this
is actually possible; a repeated state implies that the program is
in an infinite loop. The problem is that a Turing machine is not
limited to a finite number of states (including the state of the
tape), and such an analysis is not possible in the general case.
I think olcott thinks it is possible.
Subsequent wordings have all been about hiding this. Just prior to this >>> wording was the even more explicit claim that non-halting is correct
because of what "would happen if line 15 were commented out". It's
always been about what would be the correct decision were the
computation not what it actually is.
Sure, I have no doubt that olcott has written contradictory things
(to the extent that they're clear enough to be contradictory).
I just don't think he's done is on the case of this specific
statement.
I suppose Ben quoted PO saying this, because PO /uses/ it to justify
that a
particular /halting/ computation will never halt,
He may be doing that now, but he used to use this form of words to
justify why non-halting is the correct result for some halting
computations. Obviously, to keep people talking he has had to scramble >>> to get away from what he has said in the past without repudiating it.
No crank likes admit they were ever wrong.
Agreed.
On 5/23/2025 10:55 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/05/2025 19:37, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is theHmm. I don't read that the way you do. Did I miss something?
correct halting decision for some halting computations. He has said >>>>>> this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its input
would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said
Sipser
would be interpreting the oft-quoted "Sipser quote". I don't think
you've
missed anything particularly.
Maybe it makes less sense out of the context it was posted in. This was >>> when he was being less obtuse. The computation in question only halts
because it is halted by the decider on which it is built. It is a
halting computation, but according to PO it can reported as not halting
because of what would happen if it were not halted by the decider from
which it is derived.
I think you're misreading it (or, if you prefer, I have yet to be
convinced that I'm misreading it).
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Call the "halt decider" H, and the input I. If you perform the
computation specified by I, it never halts. olcott's statement
is that if H correctly determines that I never halts (assume for
now that that's possible), then H can correctly report that I
never halts. This is true, tautological, and uninteresting.
There is *another* computation, I-simulated-by-H. This computation
may halt if H decides to halt it. But I-simulated-by-H is not I.
H's alleged job is to determine the halting status of I, not the
halting status of I-simulated-by-H.
I think you're saying that H *incorrectly* reports that
I-simulated-by-H never halts. My interpretation is that H
*correctly* reports that I never halts.
The above is based only on that isolated statement, without reference
to olcott's other claims. Moving on to the larger context:
If a general solution to the halting problem were possible (we
know it isn't), a simulating halt decider could be one possible
way to approach it. It is, I suppose, a tempting idea. You could
imagine a simulator that runs a program one step at a time, and
after each step, reports that it just halted if it has, or performs
some analysis that attempts to determine that it will never halt.
If it's able to make that determination, the simulator can halt
and correctly report that the simulated program never halts.
Good and correct. You are one of my best reviewers.
If the program runs on a machine with a finite number of states, this
is actually possible; a repeated state implies that the program is
in an infinite loop. The problem is that a Turing machine is not
limited to a finite number of states (including the state of the
tape), and such an analysis is not possible in the general case.
I think olcott thinks it is possible.
Most TM's seem to have a finite number of states.
They have unlimited tape.
Subsequent wordings have all been about hiding this. Just prior to this >>> wording was the even more explicit claim that non-halting is correct
because of what "would happen if line 15 were commented out". It's
always been about what would be the correct decision were the
computation not what it actually is.
Sure, I have no doubt that olcott has written contradictory things
(to the extent that they're clear enough to be contradictory).
I just don't think he's done is on the case of this specific
statement.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
DDD simulated by HHH according to the semantics of
he x86 language remains in recursive emulation until
stopped.
I suppose Ben quoted PO saying this, because PO /uses/ it to justify
that a
particular /halting/ computation will never halt,
He may be doing that now, but he used to use this form of words to
justify why non-halting is the correct result for some halting
computations. Obviously, to keep people talking he has had to scramble >>> to get away from what he has said in the past without repudiating it.
No crank likes admit they were ever wrong.
Agreed.
On 5/24/2025 3:01 AM, Mikko wrote:
On 2025-05-23 16:19:12 +0000, olcott said:
On 5/23/2025 2:17 AM, Mikko wrote:
On 2025-05-23 05:25:30 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser >>>>>>>>> that can
correctly report for any program and any input whether it
halts. Good
luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that
my inability to write the kind of program Turing envisaged (an
inability that I readily concede) is evidence for his argument.
Well, what's sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but
no matter how clearly he explains it to me my eyes glaze over and >>>>>>> I start to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made
the front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by
creating a
Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come >>>>>> up with.)
Mike.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
That is not a valid sentence: there is an subordinate clause and two
main clauses but nothing that combines the main clauses to an overall
meaning.
Is is not supposed to be an English sentence nitwit.
Yet another attempt of a straw man deception. I didn't say anything
about English. I only said that it is not a sentence.
It is a simplification of the Linz definition of Ĥ.
A simplification that omits all meaning is not a useful simplification.
It does not define, it does not describe, it does not require, it does
not say anything at all.
If you are too stupid to understand its meaning
that is not my fault. I even specified its step
by step meaning and you erased that part to make
it easier to lie.
On 5/24/2025 11:35 AM, Mike Terry wrote:
On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said >>>>>> this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its input
would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
It would be a tautology but for the "unless..." part. It does not make >>>> the determination that it does not halt. It determines that it would >>>> not halt were it not for the fact that the decider (a simulation) in
fact halts it.
Right, so the computation itself is non-halting.
No no no, it halts! (Assuming we're discussing the computation DD()
with PO's code.)
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
_DD()
[00002162] 55 push ebp
[00002163] 8bec mov ebp,esp
[00002165] 51 push ecx
[00002166] 6862210000 push 00002162
[0000216b] e862f4ffff call 000015d2
[00002170] 83c404 add esp,+04
[00002173] 8945fc mov [ebp-04],eax
[00002176] 837dfc00 cmp dword [ebp-04],+00
[0000217a] 7402 jz 0000217e
[0000217c] ebfe jmp 0000217c
[0000217e] 8b45fc mov eax,[ebp-04]
[00002181] 8be5 mov esp,ebp
[00002183] 5d pop ebp
[00002184] c3 ret
Size in bytes:(0035) [00002184]
It is a damned lie that DD simulated by HHH according
to the rules of the x86 language ever reaches its own
machine address 00002184 final halt state.
The input to HHH(DD) specifies a non-halting sequence
of configurations.
The above two are verified facts and anyone lying about
this may be condemned to actual Hell.
At least that is what Revelations 21:8 says.
On 5/24/2025 4:59 AM, Fred. Zwarts wrote:
Op 24.mei.2025 om 02:30 schreef olcott:
On 5/23/2025 7:08 PM, Mike Terry wrote:
On 23/05/2025 19:37, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said >>>>>> this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its input
would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said
Sipser would be interpreting the oft-quoted "Sipser quote". I don't
think you've missed anything particularly.
I suppose Ben quoted PO saying this, because PO /uses/ it to justify
that a particular /halting/ computation will never halt, PO's HHH
simulates DDD (which halts) but before DDD halts it spots a pattern
in the simulation, and announces non-halting.
In other words you expect that the HHH that DD calls
to report on the behavior of its caller?
How the f-ck can it do that?
All information is present in the input specification,
int main()
{
DD; // How the f-ck do you expect HHH called by DD to report
} // on the behavior of its caller?
// How can HHH even know that DD is its caller?
including the code of DDD and all function called by DDD up to the OS-
level.
So, HHH has all the information needed to see the behaviour of the
caller.
That HHH has a bug that prevents it see the full specification does
not change the fact that the specification is in the input.
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the >>>>>>>> correct halting decision for some halting computations. He has >>>>>>>> said
this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its
input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>> | decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something? >>>>>>>
It assumes that the input is a non-halting computation ("its input >>>>>>> would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>> doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
It would be a tautology but for the "unless..." part. It does not >>>>>> make
the determination that it does not halt. It determines that it would >>>>>> not halt were it not for the fact that the decider (a simulation) in >>>>>> fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation
DD() with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is olcott's
statement:
| When-so-ever a halt decider correctly determines that its
input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>> | decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has
written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its input
(which represents a computation). I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I with
the ability to halt it. H is not a pure simulator; it does not always
fully simulate the execution of I.
H is given the task of determining whether I is a halting computation or >>> not (a task that is not possible in all cases, but is certainly possible >>> in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology. That
tautology is not very interesting, and most people would interpret the
statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some
absolute sense even if PO does not understand that sense, and is
thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the words
mean what /he/ says they mean, and that meaning justifies one of his
false claims. He supports this claim by saying Sipser agreed with the
words, even though it's clear Sipser's agreement was with a different
interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that
statement and his interpretation of what it means is far from your
tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue with
olcott, if he happens to make a true statement it's not helpful to argue >>> that its false.
I'm all for that - I'd go further to say that I champion that point of
view. But if PO makes a statement which he intends to mean XXX and
XXX is false, has he made a true statement just because your
interpretation of the same statement is YYY, different from XXX, and
YYY happens to be true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly not
me. (I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
On 5/24/2025 7:42 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:26, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/05/2025 19:37, Keith Thompson wrote:Maybe it makes less sense out of the context it was posted in. This
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is the >>>>>>> correct halting decision for some halting computations. He has said >>>>>>> this explicitly (as I have posted before) but he has alsoHmm. I don't read that the way you do. Did I miss something?
explained it
in words:
| When-so-ever a halt decider correctly determines that its input >>>>>>> would
| never halt unless forced to halt by this halt decider this halt >>>>>>> | decider has made a correct not-halting determination.
It assumes that the input is a non-halting computation ("its input >>>>>> would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input >>>>>> doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said
Sipser
would be interpreting the oft-quoted "Sipser quote". I don't think >>>>> you've
missed anything particularly.
was
when he was being less obtuse. The computation in question only halts >>>> because it is halted by the decider on which it is built. It is a
halting computation, but according to PO it can reported as not halting >>>> because of what would happen if it were not halted by the decider from >>>> which it is derived.
"The computation in question only halts because it is halted by the
decider on which it is built."
That is presumably you speaking in PO's voice, but my first reading
was as you saying it!
It was paraphrase. He has evolved (deliberately) from being very clear:
false is correct for some halting computations; the set of halting
computation is expanded to include some others; right though to the
wording that he managed to trick Sipser with.
The intermediate stages involved turns of phrase like "some computations
only halt because the simulator halts them" and "it would not halt if
line 15 were commented out" and so on. But the basic plan has been the
same for years: some halting computations can be classed as non-halting
because they halt for a reason he considers special -- a closely related
but different computation would not halt.
If PO were a normal person, the key would be to go back and forth getting
answers to direct questions that would illuminate what he thinks. But
cranks always duck and dive when asked direct questions because they
know that must avoid being clear. I have dozens of notes of direct
questions being evaded, time and time again. The only game (for me) is
to try to get a crank to actually say what they mean as clearly as
possible. That is, after all, what a proper exchange of view should be
based on.
...
As ever, pointing it out to PO, however explicitly and clearly, has no
effect on what PO believes.
Right, but it is possible to try to get as clear and concise an
expression of what he believes. There's no point in trying to change
his mind, but his nonsense can then be laid bare for all to see. At
that point, I would want to just repeat it back (every time he posts)
with an brief explanation that it's wrong rather than try to educate PO.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
On 5/24/2025 7:21 PM, olcott wrote:
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the >>>>>>>>> correct halting decision for some halting computations. He has >>>>>>>>> said
this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its
input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>> | decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something? >>>>>>>>
It assumes that the input is a non-halting computation ("its input >>>>>>>> would never halt") and asserts that, in certain circumstances, >>>>>>>> his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>>> doesn't halt, it has made a correct non-halting determination. >>>>>>>> It's just a tautology.
It would be a tautology but for the "unless..." part. It does
not make
the determination that it does not halt. It determines that it >>>>>>> would
not halt were it not for the fact that the decider (a simulation) in >>>>>>> fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation
DD() with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is olcott's >>>> statement:
| When-so-ever a halt decider correctly determines that its
input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>> | decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has
written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its input
(which represents a computation). I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I with >>>> the ability to halt it. H is not a pure simulator; it does not always >>>> fully simulate the execution of I.
H is given the task of determining whether I is a halting
computation or
not (a task that is not possible in all cases, but is certainly
possible
in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology.
That tautology is not very interesting, and most people would
interpret the statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some
absolute sense even if PO does not understand that sense, and is
thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the words
mean what /he/ says they mean, and that meaning justifies one of his
false claims. He supports this claim by saying Sipser agreed with
the words, even though it's clear Sipser's agreement was with a
different interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that
statement and his interpretation of what it means is far from your
tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue with >>>> olcott, if he happens to make a true statement it's not helpful to
argue
that its false.
I'm all for that - I'd go further to say that I champion that point
of view. But if PO makes a statement which he intends to mean XXX
and XXX is false, has he made a true statement just because your
interpretation of the same statement is YYY, different from XXX, and
YYY happens to be true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly not
me. (I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
int main()
{
DDD(); // No matter what the f-ck its caller does
} // The finite string input to the HHH(DDD)
// that DDD() calls SPECIFIES a non-halting
// sequence of configurations.
On 5/24/2025 3:01 AM, Mikko wrote:
On 2025-05-23 16:19:12 +0000, olcott said:
On 5/23/2025 2:17 AM, Mikko wrote:
On 2025-05-23 05:25:30 +0000, olcott said:
On 5/22/2025 8:24 PM, Mike Terry wrote:
On 22/05/2025 06:41, Richard Heathfield wrote:
On 22/05/2025 06:23, Keith Thompson wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 22/05/2025 00:14, olcott wrote:[...]
On 5/21/2025 6:11 PM, Richard Heathfield wrote:
Turing proved that what you're asking is impossible.That is not what he proved.
Then you'll be able to write a universal termination analyser that can
correctly report for any program and any input whether it halts. Good >>>>>>>>> luck with that.
Not necessarily.
Of course not. But I'm just reflecting. He seemed to think that my >>>>>>> inability to write the kind of program Turing envisaged (an inability >>>>>>> that I readily concede) is evidence for his argument. Well, what's >>>>>>> sauce for the goose is sauce for the gander.
Even if olcott had refuted the proofs of the
insolvability of the Halting Problem -- or even if he had proved >>>>>>>> that a universal halt decider is possible
And we both know what we both think of that idea.
-- that doesn't imply
that he or anyone else would be able to write one.
Indeed.
I've never been entirely clear on what olcott is claiming.
Nor I. Mike Terry seems to have a pretty good handle on it, but no >>>>>>> matter how clearly he explains it to me my eyes glaze over and I start >>>>>>> to snore.
Hey, it's the way I tell 'em!
Here's what the tabloids might have said about it, if it had made the >>>>>> front pages when the story broke:
COMPUTER BOFFIN IS TURING IN HIS GRAVE!
An Internet crank claims to have refuted Linz HP proof by creating a >>>>>> Halt Decider that CORRECTLY decides its own "impossible input"! >>>>>> The computing world is underwhelmed.
Better? (Appologies for the headline, it's the best I could come up with.)
Mike.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
That is not a valid sentence: there is an subordinate clause and two
main clauses but nothing that combines the main clauses to an overall
meaning.
Is is not supposed to be an English sentence nitwit.
Yet another attempt of a straw man deception. I didn't say anything
about English. I only said that it is not a sentence.
It is a simplification of the Linz definition of Ĥ.
A simplification that omits all meaning is not a useful simplification.
It does not define, it does not describe, it does not require, it does
not say anything at all.
If you are too stupid to understand its meaning
that is not my fault.
I even specified its step by step meaning and you erased that part
to make it easier to lie.
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩
(e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
(g) goto (d) with one more level of simulation
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the >>>>>>>> correct halting decision for some halting computations. He has said >>>>>>>> this explicitly (as I have posted before) but he has also explained it >>>>>>>> in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>> | decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something? >>>>>>>
It assumes that the input is a non-halting computation ("its input >>>>>>> would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>> doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
It would be a tautology but for the "unless..." part. It does not make >>>>>> the determination that it does not halt. It determines that it would >>>>>> not halt were it not for the fact that the decider (a simulation) in >>>>>> fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation DD()
with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is olcott's
statement:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>> | decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has
written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its input
(which represents a computation). I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I with
the ability to halt it. H is not a pure simulator; it does not always
fully simulate the execution of I.
H is given the task of determining whether I is a halting computation or >>> not (a task that is not possible in all cases, but is certainly possible >>> in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology. That
tautology is not very interesting, and most people would interpret the
statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some
absolute sense even if PO does not understand that sense, and is
thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the words
mean what /he/ says they mean, and that meaning justifies one of his
false claims. He supports this claim by saying Sipser agreed with the
words, even though it's clear Sipser's agreement was with a different
interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that
statement and his interpretation of what it means is far from your
tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue with
olcott, if he happens to make a true statement it's not helpful to argue >>> that its false.
I'm all for that - I'd go further to say that I champion that point of
view. But if PO makes a statement which he intends to mean XXX and XXX
is false, has he made a true statement just because your interpretation
of the same statement is YYY, different from XXX, and YYY happens to be
true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly not me.
(I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
On 5/24/2025 7:53 PM, olcott wrote:
On 5/24/2025 7:42 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:26, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/05/2025 19:37, Keith Thompson wrote:Maybe it makes less sense out of the context it was posted in. This was >>>>> when he was being less obtuse. The computation in question only halts >>>>> because it is halted by the decider on which it is built. It is a
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>> [...]Hmm. I don't read that the way you do. Did I miss something? >>>>>>> It assumes that the input is a non-halting computation ("its input >>>>>>> would never halt") and asserts that, in certain circumstances,
And the big picture is that this can be done because false is the >>>>>>>> correct halting decision for some halting computations. He has said >>>>>>>> this explicitly (as I have posted before) but he has also explained it >>>>>>>> in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>> | decider has made a correct not-halting determination.
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>> doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said Sipser
would be interpreting the oft-quoted "Sipser quote". I don't think you've
missed anything particularly.
halting computation, but according to PO it can reported as not halting >>>>> because of what would happen if it were not halted by the decider from >>>>> which it is derived.
"The computation in question only halts because it is halted by the
decider on which it is built."
That is presumably you speaking in PO's voice, but my first reading
was as you saying it!
It was paraphrase. He has evolved (deliberately) from being very clear: >>> false is correct for some halting computations; the set of halting
computation is expanded to include some others; right though to the
wording that he managed to trick Sipser with.
The intermediate stages involved turns of phrase like "some computations >>> only halt because the simulator halts them" and "it would not halt if
line 15 were commented out" and so on. But the basic plan has been the >>> same for years: some halting computations can be classed as non-halting
because they halt for a reason he considers special -- a closely related >>> but different computation would not halt.
If PO were a normal person, the key would be to go back and forth getting >>> answers to direct questions that would illuminate what he thinks. But
cranks always duck and dive when asked direct questions because they
know that must avoid being clear. I have dozens of notes of direct
questions being evaded, time and time again. The only game (for me) is >>> to try to get a crank to actually say what they mean as clearly as
possible. That is, after all, what a proper exchange of view should be >>> based on.
...
As ever, pointing it out to PO, however explicitly and clearly, has no >>>> effect on what PO believes.
Right, but it is possible to try to get as clear and concise an
expression of what he believes. There's no point in trying to change
his mind, but his nonsense can then be laid bare for all to see. At
that point, I would want to just repeat it back (every time he posts)
with an brief explanation that it's wrong rather than try to educate PO. >>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
int main()
{
DDD(); // No matter what the f-ck its caller does
} // The finite string input to the HHH(DDD)
// that DDD calls SPECIFIES a non-halting
// sequence of configurations.
On 5/24/2025 10:12 AM, dbush wrote:
On 5/24/2025 11:04 AM, olcott wrote:
On 5/23/2025 8:09 PM, dbush wrote:
On 5/23/2025 9:07 PM, olcott wrote:
On 5/23/2025 7:57 PM, dbush wrote:
On 5/23/2025 8:54 PM, olcott wrote:
On 5/23/2025 7:44 PM, dbush wrote:
On 5/23/2025 8:08 PM, Mike Terry wrote:
I suppose Ben quoted PO saying this, because PO /uses/ it to justify >>>>>>>>> that a particular /halting/ computation will never halt, PO's HHH >>>>>>>>> simulates DDD (which halts) but before DDD halts it spots a pattern in
the simulation, and announces non-halting. "Eh?" I hear you say! PO >>>>>>>>> claims HHH has "correctly determined that DDD would never halt" and so
is correct to decide non- halting. His "proof" that it is right to >>>>>>>>> decide non-halting is his "when-so- ever.." quote, which broadly >>>>>>>>> matches the Sipser quote.
So the problem is not so much the "when-so-ever.." words themselves [or
the words of Sipser's quote], but understanding how PO is so thoroughly
misinterpreting/misapplying them. How can PO believe HHH has >>>>>>>>> "correctly determined the DDD will never halt" when DDD demonstrably >>>>>>>>> halts?
PO is working in a different model than the rest of us, though he >>>>>>>> doesn't seem to understand that.
To him, when function H is deciding on something, the implementation of
H is allowed to vary. This results in functions that call H to vary as
a result. To him, "DDD" is the same computation *regardless of the >>>>>>>> implementation of HHH*, in cases where HHH is simulating DDD.
This is essentially the mapping he's operating with:
-----------------
For a function X with input Y and a function H which simulates X: >>>>>>>> POH(H,X,Y)==1 if and only if there exists an implementation of H that >>>>>>>> can simulate X(Y) to completion
POH(H,X,Y)==0 if and only if there does not exist an implementation of >>>>>>>> H that can simulate X(Y) to completion
----------------
And a "decider" in his case maps the following subset:
----------------
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y)
----------------
So given his rules, HHH1(DDD) is deciding on a algorithm while HHH(DDD)
is deciding on a C function whose subfunctions vary.
This of course has nothing to do with the halting problem but he >>>>>>>> doesn't get this. After having spent 22 years on this, he'll come up >>>>>>>> with any crazy justification to avoid admitting to himself that he >>>>>>>> misunderstood the problem all this time. He once said (and I don't >>>>>>>> recall the exact wording) that "the directly executed D doesn't halt >>>>>>>> even though it appears to".
The problem is that people here are too stupid
to notice that HHH cannot report on the behavior
of its caller.
int min()
{
DD(); // HHH cannot report on the behavior of its caller.
}
What about this?
If you can't stay exactly on topic I am going to ignore
everything that you say.
HHH cannot report on the behavior of its caller AKA the
direct execution of DD().
In other words, you again agree with Linz and others that no H exists
that can perform the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the
following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly >>>>
int main()
{
DD(); // The HHH called by DD cannot report on the behavior
} // of its caller. Is this OVER-YOUR-HEAD ?
Which means that no HHH exists that meets the below requirements, as
Linz and others proved and as you have *explicitly* agreed is correct:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
No HHH can report on the behavior of its caller
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves you're wrong
Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus
is true. Anybody putting up a contrary argument must therefore be wrong.
You might also put up a long winded argument why 2 + 2 = 5, and I would
dismiss this likewise, without bothering to follow your exact detailed
steps.
You've also tried, without success, to dismiss one of the proofs of the
Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
On 5/24/2025 4:59 AM, Fred. Zwarts wrote:
Op 24.mei.2025 om 02:30 schreef olcott:
On 5/23/2025 7:08 PM, Mike Terry wrote:
On 23/05/2025 19:37, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:[...]
And the big picture is that this can be done because false is the
correct halting decision for some halting computations. He has said >>>>>> this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its input
would
| never halt unless forced to halt by this halt decider this halt
| decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something?
It assumes that the input is a non-halting computation ("its input
would never halt") and asserts that, in certain circumstances,
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input
doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said
Sipser would be interpreting the oft-quoted "Sipser quote". I don't
think you've missed anything particularly.
I suppose Ben quoted PO saying this, because PO /uses/ it to justify
that a particular /halting/ computation will never halt, PO's HHH
simulates DDD (which halts) but before DDD halts it spots a pattern
in the simulation, and announces non-halting.
In other words you expect that the HHH that DD calls
to report on the behavior of its caller?
How the f-ck can it do that?
All information is present in the input specification,
int main()
{
DD; // How the f-ck do you expect HHH called by DD to report
} // on the behavior of its caller?
// How can HHH even know that DD is its caller?
On 5/24/2025 11:24 AM, Mr Flibble wrote:
On Sat, 24 May 2025 11:13:12 -0500, olcott wrote:
On 5/24/2025 10:12 AM, dbush wrote:
On 5/24/2025 11:04 AM, olcott wrote:You are a damned liar when you say that I said that HHH must report on
On 5/23/2025 8:09 PM, dbush wrote:
On 5/23/2025 9:07 PM, olcott wrote:int main()
On 5/23/2025 7:57 PM, dbush wrote:
On 5/23/2025 8:54 PM, olcott wrote:If you can't stay exactly on topic I am going to ignore everything >>>>>>> that you say.
On 5/23/2025 7:44 PM, dbush wrote:What about this?
On 5/23/2025 8:08 PM, Mike Terry wrote:
I suppose Ben quoted PO saying this, because PO /uses/ it to >>>>>>>>>>> justify that a particular /halting/ computation will never halt, >>>>>>>>>>> PO's HHH simulates DDD (which halts) but before DDD halts it >>>>>>>>>>> spots a pattern in the simulation, and announces non-halting. >>>>>>>>>>> "Eh?" I hear you say! PO claims HHH has "correctly determined >>>>>>>>>>> that DDD would never halt" and so is correct to decide non- >>>>>>>>>>> halting. His "proof" that it is right to decide non-halting is >>>>>>>>>>> his "when-so- ever.." quote, which broadly matches the Sipser >>>>>>>>>>> quote.
So the problem is not so much the "when-so-ever.." words >>>>>>>>>>> themselves [or the words of Sipser's quote], but understanding >>>>>>>>>>> how PO is so thoroughly misinterpreting/misapplying them. How >>>>>>>>>>> can PO believe HHH has "correctly determined the DDD will never >>>>>>>>>>> halt" when DDD demonstrably halts?
PO is working in a different model than the rest of us, though he >>>>>>>>>> doesn't seem to understand that.
To him, when function H is deciding on something, the
implementation of H is allowed to vary. This results in
functions that call H to vary as a result. To him, "DDD" is the >>>>>>>>>> same computation *regardless of the implementation of HHH*, in >>>>>>>>>> cases where HHH is simulating DDD.
This is essentially the mapping he's operating with:
-----------------
For a function X with input Y and a function H which simulates X: >>>>>>>>>> POH(H,X,Y)==1 if and only if there exists an implementation of H >>>>>>>>>> that can simulate X(Y) to completion POH(H,X,Y)==0 if and only if >>>>>>>>>> there does not exist an implementation of H that can simulate >>>>>>>>>> X(Y) to completion ----------------
And a "decider" in his case maps the following subset:
----------------
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y) >>>>>>>>>> ----------------
So given his rules, HHH1(DDD) is deciding on a algorithm while >>>>>>>>>> HHH(DDD) is deciding on a C function whose subfunctions vary. >>>>>>>>>>
This of course has nothing to do with the halting problem but he >>>>>>>>>> doesn't get this. After having spent 22 years on this, he'll >>>>>>>>>> come up with any crazy justification to avoid admitting to >>>>>>>>>> himself that he misunderstood the problem all this time. He once >>>>>>>>>> said (and I don't recall the exact wording) that "the directly >>>>>>>>>> executed D doesn't halt even though it appears to".
The problem is that people here are too stupid to notice that HHH >>>>>>>>> cannot report on the behavior of its caller.
int min()
{
DD(); // HHH cannot report on the behavior of its caller. >>>>>>>>> }
HHH cannot report on the behavior of its caller AKA the direct
execution of DD().
In other words, you again agree with Linz and others that no H exists >>>>>> that can perform the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of instructions) >>>>>> X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
{
DD(); // The HHH called by DD cannot report on the behavior
} // of its caller. Is this OVER-YOUR-HEAD ?
Which means that no HHH exists that meets the below requirements, as
Linz and others proved and as you have *explicitly* agreed is correct: >>>>
the behavior of its caller.
No HHH can report on the behavior of its caller for the same reason that >>> no function can report on the value of the square-root of a dead cat.
Analysis: Olcott’s SHD vs Classical Halting Problem (Thread on 2025-05-24) >> =========================================================================
Overview:
---------
This thread features a debate between Peter Olcott and dbush over the
validity and interpretation of Olcott’s SHD (Simulating Halt Decider). The >> discussion parallels Flibble’s ideas about semantic stratification and
simulation-based detection of infinite behavior.
Core Disagreement:
------------------
Classical Model:
- The Halting Problem asks if a universal decider H can determine whether
any program P(x) halts when executed directly.
Olcott’s SHD View:
- HHH simulates P(x) and detects infinite behavior.
- If infinite recursion is observed during simulation, it reports “non-
halting.”
- HHH cannot determine the behavior of its caller (e.g., DD()).
Philosophical Analysis:
-----------------------
1. Semantic Stratification:
- Olcott: A decider cannot report on its caller. This enforces a semantic
barrier (like Flibble’s model).
- Classical theory treats the program as a fixed object, regardless of how >> or where it is called.
2. Simulation-Based Detection:
- Olcott’s SHD works by observing simulation patterns.
- Like Flibble, Olcott allows early detection of infinite behavior without >> full execution.
- This results in a partial decider — useful but not universal.
3. Context Misunderstanding:
- Olcott sees DD() calling HHH and assumes HHH must reason about DD’s
outer frame.
- Classical theory ignores runtime context: it analyzes the semantics of
the program as a whole.
Meta-Level Behavior:
--------------------
Olcott:
- Asserts that self-reference leads to non-determinism or ill-formed
questions.
- Treats his SHD as correct for many real-world inputs.
- Undermines his position with poor rhetoric and personal insults.
dbush:
- Correctly applies classical theory.
- Dismisses Olcott's model as a misunderstanding without acknowledging
alternative interpretations.
Comparison to Flibble’s Model:
------------------------------
| Feature | Olcott's SHD | Flibble's Typed
SHD |
|---------------------------|--------------------------|-----------------------------|
| Simulation-based? | ✅ Yes | ✅
Yes |
| Infinite detection? | ✅ Runtime-based | ✅ Structural-
based |
| Caller access? | ❌ No | ❌ No (via
compiler restriction) |
| Self-reference blocked? | 🟡 By convention | ✅ By type
design |
| Semantic firewall? | 🟡 Weak | ✅
Strong |
Conclusion:
-----------
Olcott is not incorrect in claiming that SHDs can detect certain forms of
non-halting behavior. However, his failure to delineate model boundaries
leads to confusion. His SHD is a partial model — valid in practical
settings but not a refutation of the Halting Problem.
*THIS IS THE ENTIRE SPECIFICATION*
<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 D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Refutes every conventional halting problem proof.
Ignores useless nonsense such as the Busy-Beaver
that has no practical value and quickly consumes
much more memory than there are atoms in the universe.
On 5/24/2025 8:01 PM, olcott wrote:No, the input is a pointer to memory. That memory includes the code of
On 5/24/2025 7:57 PM, Ben Bacarisse wrote:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 23/05/2025 19:37, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>> [...]Hmm. I don't read that the way you do. Did I miss something? >>>>>>> It assumes that the input is a non-halting computation ("its input >>>>>>> would never halt") and asserts that, in certain circumstances,
And the big picture is that this can be done because false is the >>>>>>>> correct halting decision for some halting computations. He has >>>>>>>> said
this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its
input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>> | decider has made a correct not-halting determination.
his mythical halt decider correctly determines that the input
is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>> doesn't halt, it has made a correct non-halting determination.
It's just a tautology.
You're reading it the way most people would, and in the way I said >>>>>> Sipser
would be interpreting the oft-quoted "Sipser quote". I don't
think you've
missed anything particularly.
Maybe it makes less sense out of the context it was posted in.
This was
when he was being less obtuse. The computation in question only halts >>>>> because it is halted by the decider on which it is built. It is a
halting computation, but according to PO it can reported as not
halting
because of what would happen if it were not halted by the decider from >>>>> which it is derived.
I think you're misreading it (or, if you prefer, I have yet to be
convinced that I'm misreading it).
OK. This sub thread is an excellent example of how cranks keep it all
going without shining any light on what's going on.
If the remark is correct, then it misrepresents PO's intended meaning
because he is discussing one of the cases where false is the correct
result for a halting computation. If the remark does represent his
intended meaning then it is unclear because you think it is simply a
tautology.
That makes it a bad quote for me to have pulled out. I should have
stuck with this exchange:
Me: Here's the key question: do you still assert that H(P,P) == false is >>> the "correct" answer even though P(P) halts?
PO: Yes that is the correct answer even though P(P) halts.
Everything that followed this was, as far as I can tell, an attempt be
less clear. But as Richard Heathfield has pointed out, we should always >>> attempt to address the strongest and clearest-made point that is
offered. (I think this advice was originally from Daniel Dennet.)
I see you have offered a very detailed interpretation of what you think
the words used by PO mean. Please forgive me for not going into it in
any more detail. I'll just take that to mean PO was unclear and should >>> not have quoted his ambiguous words. When PO is clear, he is very
explicitly wrong, and that's the main point that keeps getting lost.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
int main()
{
DDD(); // No matter what the f-ck its caller does
} // The finite string input to the HHH(DDD)
// that DDD() calls SPECIFIES a non-halting
// sequence of configurations.
On 5/25/2025 5:34 AM, Mikko wrote:
On 2025-05-24 17:15:50 +0000, olcott said:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves you're
wrong
Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus >>>> is true. Anybody putting up a contrary argument must therefore be
wrong.
You might also put up a long winded argument why 2 + 2 = 5, and I would >>>> dismiss this likewise, without bothering to follow your exact detailed >>>> steps.
You've also tried, without success, to dismiss one of the proofs of the >>>> Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
People are successfull in pointing out errors in what you say.
When they point out errors it is always of this form:
"that is not the way that I memorized it". They never
ever show any actual errors in my reasoning.
If you don't
understand what they say and don't ask questions that is your problem.
They never show and actual reasoning showing that I
made any mistake. They only reiterate their own false
assumptions.
But
the success is that other readers can see that at least some of your
claims
are unjustified and even provably wrong.
If I am wrong then an error in my reasoning can be shown.
There is no error in my reasoning. People simply assume
that I must be wrong because I derive a different result
than the one that they memorized.
On 5/25/2025 7:02 AM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves you're
wrong
Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus >>>> is true. Anybody putting up a contrary argument must therefore be
wrong.
You might also put up a long winded argument why 2 + 2 = 5, and I would >>>> dismiss this likewise, without bothering to follow your exact detailed >>>> steps.
You've also tried, without success, to dismiss one of the proofs of the >>>> Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said. That they say that I
am wrong without actually addressing ANY of my
points is actionable.
No, that proof you so much dislike is clearly and quite obviously valid
to anybody with any background in mathematics at all.
It only seems that way to people not paying attention.
If I was wrong people could show how I am wrong with
reasoning. Instead they are so sure that I am wrong
that they don't bother paying any attention to what I say.
People have paid a very great deal of attention to what you've said, in
an effort to help you understand what you haven't understood. You've
failed to respond to the help offered. Instead, you've deluged this
newsgroup with falsehoods.
If that was true then they would not always make sure
to totally ignore my key points, never actually addressing
these points with reasoning at all.
That you fail to grasp this proof is entirely down to your lack of
intellectual capacity.
That you fail to see that I am correct is because you
ignore my key points.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH.
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
int main()
{
DDD(); // No matter what the f-ck its caller does
} // The finite string input to the HHH(DDD)
// that DDD() calls SPECIFIES a non-halting
// sequence of configurations.
On 5/25/2025 5:11 AM, Mikko wrote:
On 2025-05-24 16:13:12 +0000, olcott said:
On 5/24/2025 10:12 AM, dbush wrote:
On 5/24/2025 11:04 AM, olcott wrote:
On 5/23/2025 8:09 PM, dbush wrote:
On 5/23/2025 9:07 PM, olcott wrote:
On 5/23/2025 7:57 PM, dbush wrote:
On 5/23/2025 8:54 PM, olcott wrote:
On 5/23/2025 7:44 PM, dbush wrote:
On 5/23/2025 8:08 PM, Mike Terry wrote:The problem is that people here are too stupid
I suppose Ben quoted PO saying this, because PO /uses/ it to >>>>>>>>>>> justify that a particular /halting/ computation will never >>>>>>>>>>> halt, PO's HHH simulates DDD (which halts) but before DDD >>>>>>>>>>> halts it spots a pattern in the simulation, and announces >>>>>>>>>>> non- halting. "Eh?" I hear you say! PO claims HHH hasPO is working in a different model than the rest of us, though >>>>>>>>>> he doesn't seem to understand that.
"correctly determined that DDD would never halt" and so is >>>>>>>>>>> correct to decide non- halting. His "proof" that it is right >>>>>>>>>>> to decide non-halting is his "when-so- ever.." quote, which >>>>>>>>>>> broadly matches the Sipser quote.
So the problem is not so much the "when-so-ever.." words >>>>>>>>>>> themselves [or the words of Sipser's quote], but
understanding how PO is so thoroughly misinterpreting/
misapplying them. How can PO believe HHH has "correctly >>>>>>>>>>> determined the DDD will never halt" when DDD demonstrably halts? >>>>>>>>>>
To him, when function H is deciding on something, the
implementation of H is allowed to vary. This results in
functions that call H to vary as a result. To him, "DDD" is >>>>>>>>>> the same computation *regardless of the implementation of
HHH*, in cases where HHH is simulating DDD.
This is essentially the mapping he's operating with:
-----------------
For a function X with input Y and a function H which simulates X: >>>>>>>>>> POH(H,X,Y)==1 if and only if there exists an implementation of >>>>>>>>>> H that can simulate X(Y) to completion
POH(H,X,Y)==0 if and only if there does not exist an
implementation of H that can simulate X(Y) to completion
----------------
And a "decider" in his case maps the following subset:
----------------
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y) >>>>>>>>>> ----------------
So given his rules, HHH1(DDD) is deciding on a algorithm while >>>>>>>>>> HHH(DDD) is deciding on a C function whose subfunctions vary. >>>>>>>>>>
This of course has nothing to do with the halting problem but >>>>>>>>>> he doesn't get this. After having spent 22 years on this, >>>>>>>>>> he'll come up with any crazy justification to avoid admitting >>>>>>>>>> to himself that he misunderstood the problem all this time. >>>>>>>>>> He once said (and I don't recall the exact wording) that "the >>>>>>>>>> directly executed D doesn't halt even though it appears to". >>>>>>>>>
to notice that HHH cannot report on the behavior
of its caller.
int min()
{
DD(); // HHH cannot report on the behavior of its caller. >>>>>>>>> }
What about this?
If you can't stay exactly on topic I am going to ignore
everything that you say.
HHH cannot report on the behavior of its caller AKA the
direct execution of DD().
In other words, you again agree with Linz and others that no H
exists that can perform the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of
instructions) X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes
the following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
int main()
{
DD(); // The HHH called by DD cannot report on the behavior
} // of its caller. Is this OVER-YOUR-HEAD ?
Which means that no HHH exists that meets the below requirements, as
Linz and others proved and as you have *explicitly* agreed is correct:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
It is a sin to lie about another persons words.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
False. The reason is not the same. No function can report on the value of
the square root of a dead cat because a desd cat has no square root. But
eevery caller of HHH has some behaviour that includes calling HHH.
How the Hell can a C function even see its caller?
On 5/25/2025 4:50 AM, Mikko wrote:
On 2025-05-25 00:21:21 +0000, olcott said:
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the >>>>>>>>>> correct halting decision for some halting computations. He >>>>>>>>>> has said
this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>> | decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something? >>>>>>>>>
It assumes that the input is a non-halting computation ("its input >>>>>>>>> would never halt") and asserts that, in certain circumstances, >>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>> is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>>>> doesn't halt, it has made a correct non-halting determination. >>>>>>>>> It's just a tautology.
It would be a tautology but for the "unless..." part. It does >>>>>>>> not make
the determination that it does not halt. It determines that it >>>>>>>> would
not halt were it not for the fact that the decider (a
simulation) in
fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation
DD() with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is olcott's >>>>> statement:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>> | decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has
written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its input >>>>> (which represents a computation). I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I with >>>>> the ability to halt it. H is not a pure simulator; it does not always >>>>> fully simulate the execution of I.
H is given the task of determining whether I is a halting
computation or
not (a task that is not possible in all cases, but is certainly
possible
in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology.
That tautology is not very interesting, and most people would
interpret the statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some
absolute sense even if PO does not understand that sense, and is
thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the
words mean what /he/ says they mean, and that meaning justifies one
of his false claims. He supports this claim by saying Sipser agreed
with the words, even though it's clear Sipser's agreement was with a
different interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that >>>>>> statement and his interpretation of what it means is far from your >>>>>> tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue with >>>>> olcott, if he happens to make a true statement it's not helpful to
argue
that its false.
I'm all for that - I'd go further to say that I champion that point
of view. But if PO makes a statement which he intends to mean XXX
and XXX is false, has he made a true statement just because your
interpretation of the same statement is YYY, different from XXX, and
YYY happens to be true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly not
me. (I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
One cannot verify a statement that contains the word "would". That
word means that the statement refers to a counter-factual situation
but only factual situations can be verified.
But we can verify that DDD halts.
In other words you are a complete moron regarding
hypothetical possibilities. Being a complete moron
is not any actual rebuttal.
We have two cases the actual HHH/DDD input pair and
the hypothetical HHH/DDD pair where everything is the
same yet HHH never aborts.
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its caller,
and since (as your code shows) DDD is HHH's caller, we deduce that HHH
cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
For 90 years people have gotten confused
on this issue misconstruing the computation
that HHH is contained within as exactly one
and the same thing as its own input.
On 5/25/2025 4:57 AM, Mikko wrote:
On 2025-05-25 01:05:17 +0000, olcott said:
On 5/24/2025 7:53 PM, olcott wrote:
On 5/24/2025 7:42 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:26, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>
On 23/05/2025 19:37, Keith Thompson wrote:Maybe it makes less sense out of the context it was posted in.
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>> [...]Hmm. I don't read that the way you do. Did I miss something? >>>>>>>>> It assumes that the input is a non-halting computation ("its input >>>>>>>>> would never halt") and asserts that, in certain circumstances, >>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>> is non-halting.
And the big picture is that this can be done because false is the >>>>>>>>>> correct halting decision for some halting computations. He >>>>>>>>>> has said
this explicitly (as I have posted before) but he has also
explained it
in words:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>> | decider has made a correct not-halting determination.
When his mythical halt decider correctly determines that its input >>>>>>>>> doesn't halt, it has made a correct non-halting determination. >>>>>>>>> It's just a tautology.
You're reading it the way most people would, and in the way I
said Sipser
would be interpreting the oft-quoted "Sipser quote". I don't >>>>>>>> think you've
missed anything particularly.
This was
when he was being less obtuse. The computation in question only >>>>>>> halts
because it is halted by the decider on which it is built. It is a >>>>>>> halting computation, but according to PO it can reported as not
halting
because of what would happen if it were not halted by the decider >>>>>>> from
which it is derived.
"The computation in question only halts because it is halted by the >>>>>> decider on which it is built."
That is presumably you speaking in PO's voice, but my first reading >>>>>> was as you saying it!
It was paraphrase. He has evolved (deliberately) from being very
clear:
false is correct for some halting computations; the set of halting
computation is expanded to include some others; right though to the
wording that he managed to trick Sipser with.
The intermediate stages involved turns of phrase like "some
computations
only halt because the simulator halts them" and "it would not halt if >>>>> line 15 were commented out" and so on. But the basic plan has been >>>>> the
same for years: some halting computations can be classed as non-
halting
because they halt for a reason he considers special -- a closely
related
but different computation would not halt.
If PO were a normal person, the key would be to go back and forth
getting
answers to direct questions that would illuminate what he thinks. But >>>>> cranks always duck and dive when asked direct questions because they >>>>> know that must avoid being clear. I have dozens of notes of direct >>>>> questions being evaded, time and time again. The only game (for
me) is
to try to get a crank to actually say what they mean as clearly as
possible. That is, after all, what a proper exchange of view
should be
based on.
...
As ever, pointing it out to PO, however explicitly and clearly,
has no
effect on what PO believes.
Right, but it is possible to try to get as clear and concise an
expression of what he believes. There's no point in trying to change >>>>> his mind, but his nonsense can then be laid bare for all to see. At >>>>> that point, I would want to just repeat it back (every time he posts) >>>>> with an brief explanation that it's wrong rather than try to
educate PO.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
int main()
{
DDD(); // No matter what the f-ck its caller does
} // The finite string input to the HHH(DDD)
// that DDD calls SPECIFIES a non-halting
// sequence of configurations.
You forgot one exception: if HHH (the one that DDD calls) is a decider
then DDD specifies a halting sequence of configurations.
It is a tautology that any simulated input finite
string that must be aborted to prevent its infinite
simulation does specify a non-halting sequence.
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its
caller, and since (as your code shows) DDD is HHH's caller, we
deduce that HHH cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
void DDD()
{
HHH(DDD);
return;
}
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
On 5/25/2025 4:50 AM, Mikko wrote:
On 2025-05-25 00:21:21 +0000, olcott said:
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the >>>>>>>>>> correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it
in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>> | decider has made a correct not-halting determination.
Hmm. I don't read that the way you do. Did I miss something? >>>>>>>>>
It assumes that the input is a non-halting computation ("its input >>>>>>>>> would never halt") and asserts that, in certain circumstances, >>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>> is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>>>> doesn't halt, it has made a correct non-halting determination. >>>>>>>>> It's just a tautology.
It would be a tautology but for the "unless..." part. It does not make
the determination that it does not halt. It determines that it would >>>>>>>> not halt were it not for the fact that the decider (a simulation) in >>>>>>>> fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation DD()
with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is olcott's >>>>> statement:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>> | decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has
written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its input >>>>> (which represents a computation). I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I with >>>>> the ability to halt it. H is not a pure simulator; it does not always >>>>> fully simulate the execution of I.
H is given the task of determining whether I is a halting computation or >>>>> not (a task that is not possible in all cases, but is certainly possible >>>>> in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology. That >>>> tautology is not very interesting, and most people would interpret the >>>> statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some
absolute sense even if PO does not understand that sense, and is
thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the words
mean what /he/ says they mean, and that meaning justifies one of his
false claims. He supports this claim by saying Sipser agreed with the >>>> words, even though it's clear Sipser's agreement was with a different
interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that >>>>>> statement and his interpretation of what it means is far from your >>>>>> tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue with >>>>> olcott, if he happens to make a true statement it's not helpful to argue >>>>> that its false.
I'm all for that - I'd go further to say that I champion that point of >>>> view. But if PO makes a statement which he intends to mean XXX and XXX >>>> is false, has he made a true statement just because your interpretation >>>> of the same statement is YYY, different from XXX, and YYY happens to be >>>> true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly not me. >>>> (I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
One cannot verify a statement that contains the word "would". That
word means that the statement refers to a counter-factual situation
but only factual situations can be verified.
But we can verify that DDD halts.
In other words you are a complete moron regarding
hypothetical possibilities. Being a complete moron
is not any actual rebuttal.
On 5/25/2025 4:57 AM, Mikko wrote:
On 2025-05-25 01:05:17 +0000, olcott said:
On 5/24/2025 7:53 PM, olcott wrote:
On 5/24/2025 7:42 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes:
On 24/05/2025 01:26, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>
On 23/05/2025 19:37, Keith Thompson wrote:Maybe it makes less sense out of the context it was posted in. This was
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>> [...]Hmm. I don't read that the way you do. Did I miss something? >>>>>>>>> It assumes that the input is a non-halting computation ("its input >>>>>>>>> would never halt") and asserts that, in certain circumstances, >>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>> is non-halting.
And the big picture is that this can be done because false is the >>>>>>>>>> correct halting decision for some halting computations. He has said
this explicitly (as I have posted before) but he has also explained it
in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>> | decider has made a correct not-halting determination.
When his mythical halt decider correctly determines that its input >>>>>>>>> doesn't halt, it has made a correct non-halting determination. >>>>>>>>> It's just a tautology.
You're reading it the way most people would, and in the way I said Sipser
would be interpreting the oft-quoted "Sipser quote". I don't think you've
missed anything particularly.
when he was being less obtuse. The computation in question only halts >>>>>>> because it is halted by the decider on which it is built. It is a >>>>>>> halting computation, but according to PO it can reported as not halting >>>>>>> because of what would happen if it were not halted by the decider from >>>>>>> which it is derived.
"The computation in question only halts because it is halted by the >>>>>> decider on which it is built."
That is presumably you speaking in PO's voice, but my first reading >>>>>> was as you saying it!
It was paraphrase. He has evolved (deliberately) from being very clear: >>>>> false is correct for some halting computations; the set of halting
computation is expanded to include some others; right though to the
wording that he managed to trick Sipser with.
The intermediate stages involved turns of phrase like "some computations >>>>> only halt because the simulator halts them" and "it would not halt if >>>>> line 15 were commented out" and so on. But the basic plan has been the >>>>> same for years: some halting computations can be classed as non-halting >>>>> because they halt for a reason he considers special -- a closely related >>>>> but different computation would not halt.
If PO were a normal person, the key would be to go back and forth getting >>>>> answers to direct questions that would illuminate what he thinks. But >>>>> cranks always duck and dive when asked direct questions because they >>>>> know that must avoid being clear. I have dozens of notes of direct >>>>> questions being evaded, time and time again. The only game (for me) is >>>>> to try to get a crank to actually say what they mean as clearly as
possible. That is, after all, what a proper exchange of view should be >>>>> based on.
...
As ever, pointing it out to PO, however explicitly and clearly, has no >>>>>> effect on what PO believes.
Right, but it is possible to try to get as clear and concise an
expression of what he believes. There's no point in trying to change >>>>> his mind, but his nonsense can then be laid bare for all to see. At >>>>> that point, I would want to just repeat it back (every time he posts) >>>>> with an brief explanation that it's wrong rather than try to educate PO. >>>>>
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
int main()
{
DDD(); // No matter what the f-ck its caller does
} // The finite string input to the HHH(DDD)
// that DDD calls SPECIFIES a non-halting
// sequence of configurations.
You forgot one exception: if HHH (the one that DDD calls) is a decider
then DDD specifies a halting sequence of configurations.
It is a tautology that any simulated input finite
string that must be aborted to prevent its infinite
simulation does specify a non-halting sequence.
On 5/25/2025 5:11 AM, Mikko wrote:
On 2025-05-24 16:13:12 +0000, olcott said:
On 5/24/2025 10:12 AM, dbush wrote:
On 5/24/2025 11:04 AM, olcott wrote:
On 5/23/2025 8:09 PM, dbush wrote:
On 5/23/2025 9:07 PM, olcott wrote:
On 5/23/2025 7:57 PM, dbush wrote:
On 5/23/2025 8:54 PM, olcott wrote:
On 5/23/2025 7:44 PM, dbush wrote:
On 5/23/2025 8:08 PM, Mike Terry wrote:
I suppose Ben quoted PO saying this, because PO /uses/ it to justify
that a particular /halting/ computation will never halt, PO's HHH >>>>>>>>>>> simulates DDD (which halts) but before DDD halts it spots a pattern in
the simulation, and announces non- halting. "Eh?" I hear you say! PO
claims HHH has "correctly determined that DDD would never halt" and so
is correct to decide non- halting. His "proof" that it is right to
decide non-halting is his "when-so- ever.." quote, which broadly >>>>>>>>>>> matches the Sipser quote.
So the problem is not so much the "when-so-ever.." words themselves [or
the words of Sipser's quote], but understanding how PO is so thoroughly
misinterpreting/misapplying them. How can PO believe HHH has >>>>>>>>>>> "correctly determined the DDD will never halt" when DDD demonstrably
halts?
PO is working in a different model than the rest of us, though he >>>>>>>>>> doesn't seem to understand that.
To him, when function H is deciding on something, the implementation of
H is allowed to vary. This results in functions that call H to vary as
a result. To him, "DDD" is the same computation *regardless of the >>>>>>>>>> implementation of HHH*, in cases where HHH is simulating DDD. >>>>>>>>>>
This is essentially the mapping he's operating with:
-----------------
For a function X with input Y and a function H which simulates X: >>>>>>>>>> POH(H,X,Y)==1 if and only if there exists an implementation of H that
can simulate X(Y) to completion
POH(H,X,Y)==0 if and only if there does not exist an implementation of
H that can simulate X(Y) to completion
----------------
And a "decider" in his case maps the following subset:
----------------
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y) >>>>>>>>>> ----------------
So given his rules, HHH1(DDD) is deciding on a algorithm while HHH(DDD)
is deciding on a C function whose subfunctions vary.
This of course has nothing to do with the halting problem but he >>>>>>>>>> doesn't get this. After having spent 22 years on this, he'll come up
with any crazy justification to avoid admitting to himself that he >>>>>>>>>> misunderstood the problem all this time. He once said (and I don't >>>>>>>>>> recall the exact wording) that "the directly executed D doesn't halt >>>>>>>>>> even though it appears to".
The problem is that people here are too stupid
to notice that HHH cannot report on the behavior
of its caller.
int min()
{
DD(); // HHH cannot report on the behavior of its caller. >>>>>>>>> }
What about this?
If you can't stay exactly on topic I am going to ignore
everything that you say.
HHH cannot report on the behavior of its caller AKA the
direct execution of DD().
In other words, you again agree with Linz and others that no H exists >>>>>> that can perform the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of instructions) X >>>>>> described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed directly
int main()
{
DD(); // The HHH called by DD cannot report on the behavior
} // of its caller. Is this OVER-YOUR-HEAD ?
Which means that no HHH exists that meets the below requirements, as
Linz and others proved and as you have *explicitly* agreed is correct:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
It is a sin to lie about another persons words.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
False. The reason is not the same. No function can report on the value of
the square root of a dead cat because a desd cat has no square root. But
eevery caller of HHH has some behaviour that includes calling HHH.
How the Hell can a C function even see its caller?
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its caller,
and since (as your code shows) DDD is HHH's caller, we deduce that HHH
cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
On 5/25/2025 5:34 AM, Mikko wrote:
On 2025-05-24 17:15:50 +0000, olcott said:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves you're wrong >>>>Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus >>>> is true. Anybody putting up a contrary argument must therefore be wrong. >>>>
You might also put up a long winded argument why 2 + 2 = 5, and I would >>>> dismiss this likewise, without bothering to follow your exact detailed >>>> steps.
You've also tried, without success, to dismiss one of the proofs of the >>>> Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
People are successfull in pointing out errors in what you say.
When they point out errors it is always of this form:
"that is not the way that I memorized it".
They never ever show any actual errors in my reasoning.
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
When your opponents point to the Turing proof that proves you're wrong
Without going through all of the detailed steps that I present that is
a reckless disregard for the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus
is true. Anybody putting up a contrary argument must therefore be
wrong.
On 5/25/2025 5:18 AM, Mikko wrote:
On 2025-05-24 16:38:58 +0000, olcott said:
On 5/24/2025 11:24 AM, Mr Flibble wrote:
On Sat, 24 May 2025 11:13:12 -0500, olcott wrote:
On 5/24/2025 10:12 AM, dbush wrote:Analysis: Olcott’s SHD vs Classical Halting Problem (Thread on 2025-05-24)
On 5/24/2025 11:04 AM, olcott wrote:You are a damned liar when you say that I said that HHH must report on >>>>> the behavior of its caller.
On 5/23/2025 8:09 PM, dbush wrote:
On 5/23/2025 9:07 PM, olcott wrote:int main()
On 5/23/2025 7:57 PM, dbush wrote:
On 5/23/2025 8:54 PM, olcott wrote:If you can't stay exactly on topic I am going to ignore everything >>>>>>>>> that you say.
On 5/23/2025 7:44 PM, dbush wrote:What about this?
On 5/23/2025 8:08 PM, Mike Terry wrote:
I suppose Ben quoted PO saying this, because PO /uses/ it to >>>>>>>>>>>>> justify that a particular /halting/ computation will never halt, >>>>>>>>>>>>> PO's HHH simulates DDD (which halts) but before DDD halts it >>>>>>>>>>>>> spots a pattern in the simulation, and announces non-halting. >>>>>>>>>>>>> "Eh?" I hear you say! PO claims HHH has "correctly determined >>>>>>>>>>>>> that DDD would never halt" and so is correct to decide non- >>>>>>>>>>>>> halting. His "proof" that it is right to decide non-halting is >>>>>>>>>>>>> his "when-so- ever.." quote, which broadly matches the Sipser >>>>>>>>>>>>> quote.
So the problem is not so much the "when-so-ever.." words >>>>>>>>>>>>> themselves [or the words of Sipser's quote], but understanding >>>>>>>>>>>>> how PO is so thoroughly misinterpreting/misapplying them. How >>>>>>>>>>>>> can PO believe HHH has "correctly determined the DDD will never >>>>>>>>>>>>> halt" when DDD demonstrably halts?
PO is working in a different model than the rest of us, though he >>>>>>>>>>>> doesn't seem to understand that.
To him, when function H is deciding on something, the
implementation of H is allowed to vary. This results in >>>>>>>>>>>> functions that call H to vary as a result. To him, "DDD" is the >>>>>>>>>>>> same computation *regardless of the implementation of HHH*, in >>>>>>>>>>>> cases where HHH is simulating DDD.
This is essentially the mapping he's operating with:
-----------------
For a function X with input Y and a function H which simulates X: >>>>>>>>>>>> POH(H,X,Y)==1 if and only if there exists an implementation of H >>>>>>>>>>>> that can simulate X(Y) to completion POH(H,X,Y)==0 if and only if >>>>>>>>>>>> there does not exist an implementation of H that can simulate >>>>>>>>>>>> X(Y) to completion ----------------
And a "decider" in his case maps the following subset: >>>>>>>>>>>>
----------------
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y) >>>>>>>>>>>> ----------------
So given his rules, HHH1(DDD) is deciding on a algorithm while >>>>>>>>>>>> HHH(DDD) is deciding on a C function whose subfunctions vary. >>>>>>>>>>>>
This of course has nothing to do with the halting problem but he >>>>>>>>>>>> doesn't get this. After having spent 22 years on this, he'll >>>>>>>>>>>> come up with any crazy justification to avoid admitting to >>>>>>>>>>>> himself that he misunderstood the problem all this time. He once >>>>>>>>>>>> said (and I don't recall the exact wording) that "the directly >>>>>>>>>>>> executed D doesn't halt even though it appears to".
The problem is that people here are too stupid to notice that HHH >>>>>>>>>>> cannot report on the behavior of its caller.
int min()
{
DD(); // HHH cannot report on the behavior of its caller. >>>>>>>>>>> }
HHH cannot report on the behavior of its caller AKA the direct >>>>>>>>> execution of DD().
In other words, you again agree with Linz and others that no H exists >>>>>>>> that can perform the following mapping:
Given any algorithm (i.e. a fixed immutable sequence of instructions) >>>>>>>> X described as <X> with input Y:
A solution to the halting problem is an algorithm H that computes the >>>>>>>> following mapping:
(<X>,Y) maps to 1 if and only if X(Y) halts when executed directly >>>>>>>> (<X>,Y) maps to 0 if and only if X(Y) does not halt when executed >>>>>>>> directly
{
DD(); // The HHH called by DD cannot report on the behavior >>>>>>> } // of its caller. Is this OVER-YOUR-HEAD ?
Which means that no HHH exists that meets the below requirements, as >>>>>> Linz and others proved and as you have *explicitly* agreed is correct: >>>>>>
No HHH can report on the behavior of its caller for the same reason that >>>>> no function can report on the value of the square-root of a dead cat. >>>>
========================================================================= >>>>
Overview:
---------
This thread features a debate between Peter Olcott and dbush over the
validity and interpretation of Olcott’s SHD (Simulating Halt Decider). The
discussion parallels Flibble’s ideas about semantic stratification and >>>> simulation-based detection of infinite behavior.
Core Disagreement:
------------------
Classical Model:
- The Halting Problem asks if a universal decider H can determine whether >>>> any program P(x) halts when executed directly.
Olcott’s SHD View:
- HHH simulates P(x) and detects infinite behavior.
- If infinite recursion is observed during simulation, it reports “non- >>>> halting.”
- HHH cannot determine the behavior of its caller (e.g., DD()).
Philosophical Analysis:
-----------------------
1. Semantic Stratification:
- Olcott: A decider cannot report on its caller. This enforces a semantic >>>> barrier (like Flibble’s model).
- Classical theory treats the program as a fixed object, regardless of how >>>> or where it is called.
2. Simulation-Based Detection:
- Olcott’s SHD works by observing simulation patterns.
- Like Flibble, Olcott allows early detection of infinite behavior without >>>> full execution.
- This results in a partial decider — useful but not universal.
3. Context Misunderstanding:
- Olcott sees DD() calling HHH and assumes HHH must reason about DD’s >>>> outer frame.
- Classical theory ignores runtime context: it analyzes the semantics of >>>> the program as a whole.
Meta-Level Behavior:
--------------------
Olcott:
- Asserts that self-reference leads to non-determinism or ill-formed
questions.
- Treats his SHD as correct for many real-world inputs.
- Undermines his position with poor rhetoric and personal insults.
dbush:
- Correctly applies classical theory.
- Dismisses Olcott's model as a misunderstanding without acknowledging >>>> alternative interpretations.
Comparison to Flibble’s Model:
------------------------------
| Feature | Olcott's SHD | Flibble's Typed
SHD |
|---------------------------|--------------------------|-----------------------------|
| Simulation-based? | ✅ Yes | ✅
Yes |
| Infinite detection? | ✅ Runtime-based | ✅ Structural-
based |
| Caller access? | ❌ No | ❌ No (via
compiler restriction) |
| Self-reference blocked? | 🟡 By convention | ✅ By type
design |
| Semantic firewall? | 🟡 Weak | ✅
Strong |
Conclusion:
-----------
Olcott is not incorrect in claiming that SHDs can detect certain forms of >>>> non-halting behavior. However, his failure to delineate model boundaries >>>> leads to confusion. His SHD is a partial model — valid in practical
settings but not a refutation of the Halting Problem.
*THIS IS THE ENTIRE SPECIFICATION*
<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 D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
Refutes every conventional halting problem proof.
Ignores useless nonsense such as the Busy-Beaver
that has no practical value and quickly consumes
much more memory than there are atoms in the universe.
If you had a busy-beaver oracle you could construct a halting oracle.
I am not referring to the fantasy land idea of any
oracle, nor a majick genie. DDD emulated by HHH
DOES NOT HALT.
With a halting oracle you could solve many currently unsolved problems.
Maybe you don't see any practical value in any of the problems a
halting oracle could solve, including practical halting problems,
but others certainly do.
On 5/25/2025 12:48 PM, Richard Heathfield wrote:HHH needs to report on the input. It is irrelevant whether it is its
On 25/05/2025 16:55, olcott wrote:
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its caller,
and since (as your code shows) DDD is HHH's caller, we deduce that
HHH cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
Its input, as you show by the notation HHH(DDD), is DDD. So it's
reporting on DDD.
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
But as this code shows:
void DDD()
{
; HHH(DDD);
; return;
}
DDD calls HHH. Therefore DDD is HHH's caller.
DDD is HHH's caller AND its input.
The requirement for HHH to report on the direct
execution of its input is WRONG because this require
HHH to report on the behavior of its caller and no
C function can see its own caller.
no
C function can see its own caller.
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 11:10 AM, Richard Heathfield wrote:
On 26/05/2025 16:42, olcott wrote:
no
C function can see its own caller.
So because DDD calls HHH, HHH can't analyse the halting
behaviour of DDD.
Got it.
I didn't say that.
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
Functions computed by models of computation are only
allowed to compute the mapping FROM THEIR INPUTS.
On 5/26/2025 3:51 AM, Mikko wrote:
On 2025-05-25 14:10:51 +0000, olcott said:
On 5/25/2025 4:50 AM, Mikko wrote:
On 2025-05-25 00:21:21 +0000, olcott said:
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>> On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false >>>>>>>>>>>> is theHmm. I don't read that the way you do. Did I miss something? >>>>>>>>>>>
correct halting decision for some halting computations. He >>>>>>>>>>>> has said
this explicitly (as I have posted before) but he has also >>>>>>>>>>>> explained it
in words:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this >>>>>>>>>>>> halt
| decider has made a correct not-halting determination. >>>>>>>>>>>
It assumes that the input is a non-halting computation ("its >>>>>>>>>>> input
would never halt") and asserts that, in certain circumstances, >>>>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>>>> is non-halting.
When his mythical halt decider correctly determines that its >>>>>>>>>>> input
doesn't halt, it has made a correct non-halting determination. >>>>>>>>>>> It's just a tautology.
It would be a tautology but for the "unless..." part. It does >>>>>>>>>> not make
the determination that it does not halt. It determines that >>>>>>>>>> it would
not halt were it not for the fact that the decider (a
simulation) in
fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation
DD() with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is
olcott's
statement:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this >>>>>>>>>>>> halt
| decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has >>>>>>> written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its
input
(which represents a computation). I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I >>>>>>> with
the ability to halt it. H is not a pure simulator; it does not >>>>>>> always
fully simulate the execution of I.
H is given the task of determining whether I is a halting
computation or
not (a task that is not possible in all cases, but is certainly
possible
in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology.
That tautology is not very interesting, and most people would
interpret the statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some >>>>>> absolute sense even if PO does not understand that sense, and is
thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the
words mean what /he/ says they mean, and that meaning justifies
one of his false claims. He supports this claim by saying Sipser >>>>>> agreed with the words, even though it's clear Sipser's agreement
was with a different interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that >>>>>>>> statement and his interpretation of what it means is far from your >>>>>>>> tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue >>>>>>> with
olcott, if he happens to make a true statement it's not helpful
to argue
that its false.
I'm all for that - I'd go further to say that I champion that
point of view. But if PO makes a statement which he intends to
mean XXX and XXX is false, has he made a true statement just
because your interpretation of the same statement is YYY,
different from XXX, and YYY happens to be true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly
not me. (I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
One cannot verify a statement that contains the word "would". That
word means that the statement refers to a counter-factual situation
but only factual situations can be verified.
But we can verify that DDD halts.
In other words you are a complete moron regarding
hypothetical possibilities. Being a complete moron
is not any actual rebuttal.
I'm not stupid enough to believe that we can learn about a counter-
factual
hypotetical situation by looking at it and seeing what happens.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 4:03 AM, Mikko wrote:
On 2025-05-25 14:20:30 +0000, olcott said:
On 5/25/2025 4:57 AM, Mikko wrote:
On 2025-05-25 01:05:17 +0000, olcott said:
On 5/24/2025 7:53 PM, olcott wrote:
On 5/24/2025 7:42 PM, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>
On 24/05/2025 01:26, Ben Bacarisse wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>>
On 23/05/2025 19:37, Keith Thompson wrote:Maybe it makes less sense out of the context it was posted in. >>>>>>>>> This was
Ben Bacarisse <ben@bsb.me.uk> writes:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> >>>>>>>>>>>> writes:[...]
And the big picture is that this can be done because false >>>>>>>>>>>> is thewould never halt") and asserts that, in certain circumstances, >>>>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>>>> is non-halting.
correct halting decision for some halting computations. He >>>>>>>>>>>> has said
this explicitly (as I have posted before) but he has also >>>>>>>>>>>> explained it
in words:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this >>>>>>>>>>>> halt
| decider has made a correct not-halting determination. >>>>>>>>>>> Hmm. I don't read that the way you do. Did I miss something? >>>>>>>>>>> It assumes that the input is a non-halting computation ("its >>>>>>>>>>> input
When his mythical halt decider correctly determines that its >>>>>>>>>>> input
doesn't halt, it has made a correct non-halting determination. >>>>>>>>>>> It's just a tautology.
You're reading it the way most people would, and in the way I >>>>>>>>>> said Sipser
would be interpreting the oft-quoted "Sipser quote". I don't >>>>>>>>>> think you've
missed anything particularly.
when he was being less obtuse. The computation in question >>>>>>>>> only halts
because it is halted by the decider on which it is built. It is a >>>>>>>>> halting computation, but according to PO it can reported as not >>>>>>>>> halting
because of what would happen if it were not halted by the
decider from
which it is derived.
"The computation in question only halts because it is halted by the >>>>>>>> decider on which it is built."
That is presumably you speaking in PO's voice, but my first reading >>>>>>>> was as you saying it!
It was paraphrase. He has evolved (deliberately) from being very >>>>>>> clear:
false is correct for some halting computations; the set of halting >>>>>>> computation is expanded to include some others; right though to the >>>>>>> wording that he managed to trick Sipser with.
The intermediate stages involved turns of phrase like "some
computations
only halt because the simulator halts them" and "it would not
halt if
line 15 were commented out" and so on. But the basic plan has
been the
same for years: some halting computations can be classed as non- >>>>>>> halting
because they halt for a reason he considers special -- a closely >>>>>>> related
but different computation would not halt.
If PO were a normal person, the key would be to go back and forth >>>>>>> getting
answers to direct questions that would illuminate what he thinks. >>>>>>> But
cranks always duck and dive when asked direct questions because they >>>>>>> know that must avoid being clear. I have dozens of notes of direct >>>>>>> questions being evaded, time and time again. The only game (for >>>>>>> me) is
to try to get a crank to actually say what they mean as clearly as >>>>>>> possible. That is, after all, what a proper exchange of view
should be
based on.
...
As ever, pointing it out to PO, however explicitly and clearly, >>>>>>>> has no
effect on what PO believes.
Right, but it is possible to try to get as clear and concise an
expression of what he believes. There's no point in trying to
change
his mind, but his nonsense can then be laid bare for all to see. At >>>>>>> that point, I would want to just repeat it back (every time he
posts)
with an brief explanation that it's wrong rather than try to
educate PO.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
I can't imagine how anyone disagreeing with this
is not a damned liar. If anyone disagrees knowing
that they simply don't understand these things
they too are also damned liars.
int main()
{
DDD(); // No matter what the f-ck its caller does
} // The finite string input to the HHH(DDD)
// that DDD calls SPECIFIES a non-halting
// sequence of configurations.
You forgot one exception: if HHH (the one that DDD calls) is a decider >>>> then DDD specifies a halting sequence of configurations.
It is a tautology that any simulated input finite
string that must be aborted to prevent its infinite
simulation does specify a non-halting sequence.
Irrelevant
This is the most important aspect of simulating halt deciders.
When-so-ever any simulated input must be aborted to prevent its
own infinite simulation
THEN THIS INPUT IS CORRECTLY REJECTED AS NON-HALTING
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 12:25 PM, Richard Heathfield wrote:
On 26/05/2025 17:24, olcott wrote:
On 5/26/2025 11:10 AM, Richard Heathfield wrote:
On 26/05/2025 16:42, olcott wrote:
no
C function can see its own caller.
So because DDD calls HHH, HHH can't analyse the halting behaviour of
DDD.
Got it.
I didn't say that.
Yes, you did.
On 24/5/2025 in Message-ID <100sr6o$ppn2$3@dont-email.me> you said:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
Your words.
Since DDD is HHH's caller, according to you HHH can't report on DDD's
behaviour.
HHH(DDD) does correctly report on the behavior that its
input specifies.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 4:43 AM, Mikko wrote:
On 2025-05-25 15:55:42 +0000, olcott said:
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its caller,
and since (as your code shows) DDD is HHH's caller, we deduce that
HHH cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
If the caller is DDD then the input specifies a halting behaviour because
DDD calls HHH with an input that specifies a halting behavour. But HHH
cannot correctly reject a halting input as non-halting.
The requirements of a halting decider cannot be met if the decider
reports
differently dependig on who calls it. Consequently, HHH is required to
return true also when the following FFF calls it:
void FFF(void) {
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 4:55 AM, Mikko wrote:
On 2025-05-25 14:32:14 +0000, olcott said:
On 5/25/2025 5:34 AM, Mikko wrote:
On 2025-05-24 17:15:50 +0000, olcott said:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves you're >>>>>>>> wrong
Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, >>>>>> thus
is true. Anybody putting up a contrary argument must therefore be >>>>>> wrong.
You might also put up a long winded argument why 2 + 2 = 5, and I
would
dismiss this likewise, without bothering to follow your exact
detailed
steps.
You've also tried, without success, to dismiss one of the proofs
of the
Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
People are successfull in pointing out errors in what you say.
When they point out errors it is always of this form:
"that is not the way that I memorized it".
If you were not lying you could point at least one pointer to a such
message. But you can't.
They never ever show any actual errors in my reasoning.
They do. For eample:
On Sat, 24 May 2025 17:07:11 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
When your opponents point to the Turing proof that proves you're wrong >>>Without going through all of the detailed steps that I present that is >>>> a reckless disregard for the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus >>> is true. Anybody putting up a contrary argument must therefore be
wrong.
That shows an actual error in your reasoning. You can't show any actual
error in Alan Mackenzie'sreasoning above.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The key mistake of the conventional halting problem proofs
is that they do not require the halt decider to report on
the actual behavior actually specified by the input.
When HHH(DDD) computes the mapping from its finite string
input to the behavior that it actually specifies,
we see
that the emulated DDD will continue to call HHH(DDD) in
recursive emulation
never able to reach its own emulated
"ret" instruction final halt state.
The recursive emulation invariant is that the emulated
DDD never reaches its own emulated "ret" instruction final
halt state,
On 5/26/2025 1:19 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:14 schreef olcott:
On 5/26/2025 4:55 AM, Mikko wrote:
On 2025-05-25 14:32:14 +0000, olcott said:
On 5/25/2025 5:34 AM, Mikko wrote:
On 2025-05-24 17:15:50 +0000, olcott said:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves
you're wrong
Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been
proven, thus
is true. Anybody putting up a contrary argument must therefore >>>>>>>> be wrong.
You might also put up a long winded argument why 2 + 2 = 5, and >>>>>>>> I would
dismiss this likewise, without bothering to follow your exact
detailed
steps.
You've also tried, without success, to dismiss one of the proofs >>>>>>>> of the
Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
People are successfull in pointing out errors in what you say.
When they point out errors it is always of this form:
"that is not the way that I memorized it".
If you were not lying you could point at least one pointer to a such
message. But you can't.
They never ever show any actual errors in my reasoning.
They do. For eample:
On Sat, 24 May 2025 17:07:11 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
When your opponents point to the Turing proof that proves you're >>>>>>> wrong
Without going through all of the detailed steps that I present
that is
a reckless disregard for the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven,
thus
is true. Anybody putting up a contrary argument must therefore be
wrong.
That shows an actual error in your reasoning. You can't show any actual >>>> error in Alan Mackenzie'sreasoning above.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The key mistake of the conventional halting problem proofs
is that they do not require the halt decider to report on
the actual behavior actually specified by the input.
They do. The input is a pointer to memory. This memory includes DDD
and all functions called by it directly and in directly, including the
code of Halt7.c, which specifies the abort, which makes that the input
specifies a halting program.
When HHH(DDD) computes the mapping from its finite string
input to the behavior that it actually specifies,
namely, a program that aborts and halts,
we see
that the emulated DDD will continue to call HHH(DDD) in
finite
recursive emulation
but unable to reach the emulated 'ret' instruction, because of a
premature abort. So, its mapping is incorrect, because it does not
find the behaviour that is actually specified. This bug makes that it is
never able to reach its own emulated
"ret" instruction final halt state.
The recursive emulation invariant is that the emulated
DDD never reaches its own emulated "ret" instruction final
halt state,
because it is aborted prematurely. This failure of HHH to reach the
'ret' instruction, does not change the specification in the input. It
only shows that the programmer made a mistake when he coded the abort
code.
Counter-factual.
DDD emulated by HHH1 calls HHH(DDD) and this call returns
DDD emulated by HHH calls HHH(DDD) and this call CANNOT POSSIBLY RETURN
Everyone that tries to rebut what I said has hidden
false assumptions that could be show if they provide
100% of all of the details of their reasoning.
On 5/26/2025 12:25 PM, Richard Heathfield wrote:
On 26/05/2025 17:24, olcott wrote:
On 5/26/2025 11:10 AM, Richard Heathfield wrote:
On 26/05/2025 16:42, olcott wrote:
no
C function can see its own caller.
So because DDD calls HHH, HHH can't analyse the halting
behaviour of DDD.
Got it.
I didn't say that.
Yes, you did.
On 24/5/2025 in Message-ID <100sr6o$ppn2$3@dont-email.me> you
said:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
Your words.
Since DDD is HHH's caller, according to you HHH can't report on
DDD's behaviour.
HHH(DDD) does correctly report on the behavior that its
input specifies.
On 5/26/2025 2:14 PM, Richard Heathfield wrote:We are not interested in the caller, because it is irrelevant. The input
On 26/05/2025 18:29, olcott wrote:
On 5/26/2025 12:25 PM, Richard Heathfield wrote:
On 26/05/2025 17:24, olcott wrote:
On 5/26/2025 11:10 AM, Richard Heathfield wrote:
On 26/05/2025 16:42, olcott wrote:
no
C function can see its own caller.
So because DDD calls HHH, HHH can't analyse the halting behaviour
of DDD.
Got it.
I didn't say that.
Yes, you did.
On 24/5/2025 in Message-ID <100sr6o$ppn2$3@dont-email.me> you said:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
Your words.
Since DDD is HHH's caller, according to you HHH can't report on
DDD's behaviour.
HHH(DDD) does correctly report on the behavior that its
input specifies.
It can't. Mr Olcott said so. (See above.) You /do/ believe him, right?
In other words you are pretending to be so stupid that
you don't know that the word *INPUT* and the word *CALLER*
are not the exact same word?
Now DDD is not the caller of HHH
On 5/26/2025 2:14 PM, Richard Heathfield wrote:
On 26/05/2025 18:29, olcott wrote:
On 5/26/2025 12:25 PM, Richard Heathfield wrote:
On 26/05/2025 17:24, olcott wrote:
On 5/26/2025 11:10 AM, Richard Heathfield wrote:
On 26/05/2025 16:42, olcott wrote:
no
C function can see its own caller.
So because DDD calls HHH, HHH can't analyse the halting
behaviour of DDD.
Got it.
I didn't say that.
Yes, you did.
On 24/5/2025 in Message-ID <100sr6o$ppn2$3@dont-email.me> you
said:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
Your words.
Since DDD is HHH's caller, according to you HHH can't report
on DDD's behaviour.
HHH(DDD) does correctly report on the behavior that its
input specifies.
It can't. Mr Olcott said so. (See above.) You /do/ believe him,
right?
In other words you are pretending to be so stupid that
you don't know that the word *INPUT* and the word *CALLER*
are not the exact same word?
On 5/25/2025 12:48 PM, Richard Heathfield wrote:
On 25/05/2025 16:55, olcott wrote:
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its caller,
and since (as your code shows) DDD is HHH's caller, we deduce that
HHH cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
Its input, as you show by the notation HHH(DDD), is DDD. So it's
reporting on DDD.
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
But as this code shows:
void DDD()
{
; HHH(DDD);
; return;
}
DDD calls HHH. Therefore DDD is HHH's caller.
DDD is HHH's caller AND its input.
The requirement for HHH to report on the direct
execution of its input is WRONG because this require
HHH to report on the behavior of its caller and no
C function can see its own caller.
On 5/26/2025 3:51 AM, Mikko wrote:
On 2025-05-25 14:10:51 +0000, olcott said:
On 5/25/2025 4:50 AM, Mikko wrote:
On 2025-05-25 00:21:21 +0000, olcott said:
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>> On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false >>>>>>>>>>>> is theHmm. I don't read that the way you do. Did I miss something? >>>>>>>>>>>
correct halting decision for some halting computations. He >>>>>>>>>>>> has said
this explicitly (as I have posted before) but he has also >>>>>>>>>>>> explained it
in words:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this >>>>>>>>>>>> halt
| decider has made a correct not-halting determination. >>>>>>>>>>>
It assumes that the input is a non-halting computation ("its >>>>>>>>>>> input
would never halt") and asserts that, in certain circumstances, >>>>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>>>> is non-halting.
When his mythical halt decider correctly determines that its >>>>>>>>>>> input
doesn't halt, it has made a correct non-halting determination. >>>>>>>>>>> It's just a tautology.
It would be a tautology but for the "unless..." part. It does >>>>>>>>>> not make
the determination that it does not halt. It determines that >>>>>>>>>> it would
not halt were it not for the fact that the decider (a
simulation) in
fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation
DD() with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is
olcott's
statement:
| When-so-ever a halt decider correctly determines that its >>>>>>>>>>>> input would
| never halt unless forced to halt by this halt decider this >>>>>>>>>>>> halt
| decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has >>>>>>> written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its
input
(which represents a computation). I by itself does not halt.
I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I >>>>>>> with
the ability to halt it. H is not a pure simulator; it does not >>>>>>> always
fully simulate the execution of I.
H is given the task of determining whether I is a halting
computation or
not (a task that is not possible in all cases, but is certainly
possible
in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology.
That tautology is not very interesting, and most people would
interpret the statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some >>>>>> absolute sense even if PO does not understand that sense, and is
thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the
words mean what /he/ says they mean, and that meaning justifies
one of his false claims. He supports this claim by saying Sipser >>>>>> agreed with the words, even though it's clear Sipser's agreement
was with a different interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that >>>>>>>> statement and his interpretation of what it means is far from your >>>>>>>> tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue >>>>>>> with
olcott, if he happens to make a true statement it's not helpful
to argue
that its false.
I'm all for that - I'd go further to say that I champion that
point of view. But if PO makes a statement which he intends to
mean XXX and XXX is false, has he made a true statement just
because your interpretation of the same statement is YYY,
different from XXX, and YYY happens to be true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly
not me. (I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
One cannot verify a statement that contains the word "would". That
word means that the statement refers to a counter-factual situation
but only factual situations can be verified.
But we can verify that DDD halts.
In other words you are a complete moron regarding
hypothetical possibilities. Being a complete moron
is not any actual rebuttal.
I'm not stupid enough to believe that we can learn about a counter-
factual
hypotetical situation by looking at it and seeing what happens.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/25/2025 12:48 PM, Richard Heathfield wrote:
On 25/05/2025 16:55, olcott wrote:
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its caller,
and since (as your code shows) DDD is HHH's caller, we deduce that HHH >>>> cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
Its input, as you show by the notation HHH(DDD), is DDD. So it's
reporting on DDD.
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
But as this code shows:
void DDD()
{
HHH(DDD);
return;
}
DDD calls HHH. Therefore DDD is HHH's caller.
DDD is HHH's caller AND its input.
The requirement for HHH to report on the direct
execution of its input is WRONG because this require
HHH to report on the behavior of its caller and no
C function can see its own caller.
On 26/05/2025 20:35, Fred. Zwarts wrote:
Now DDD is not the caller of HHH
Yes, it is.
void DDD()
{
HHH(DDD);
return;
}
Op 26.mei.2025 om 17:57 schreef olcott:
On 5/26/2025 3:51 AM, Mikko wrote:
On 2025-05-25 14:10:51 +0000, olcott said:
On 5/25/2025 4:50 AM, Mikko wrote:
On 2025-05-25 00:21:21 +0000, olcott said:
On 5/24/2025 6:13 PM, Mike Terry wrote:
On 24/05/2025 22:40, Keith Thompson wrote:
Mike Terry <news.dead.person.stones@darjeeling.plus.com> writes: >>>>>>>>> On 24/05/2025 01:36, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:Right, so the computation itself is non-halting.
Ben Bacarisse <ben@bsb.me.uk> writes:
[...]
And the big picture is that this can be done because false is the >>>>>>>>>>>>> correct halting decision for some halting computations. He has saidHmm. I don't read that the way you do. Did I miss something? >>>>>>>>>>>>
this explicitly (as I have posted before) but he has also explained it
in words:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>>>>> | decider has made a correct not-halting determination. >>>>>>>>>>>>
It assumes that the input is a non-halting computation ("its input >>>>>>>>>>>> would never halt") and asserts that, in certain circumstances, >>>>>>>>>>>> his mythical halt decider correctly determines that the input >>>>>>>>>>>> is non-halting.
When his mythical halt decider correctly determines that its input >>>>>>>>>>>> doesn't halt, it has made a correct non-halting determination. >>>>>>>>>>>> It's just a tautology.
It would be a tautology but for the "unless..." part. It does not make
the determination that it does not halt. It determines that it would
not halt were it not for the fact that the decider (a simulation) in
fact halts it.
No no no, it halts!
What halts?
(Assuming we're discussing the computation DD()
with PO's code.)
No, I'm not going to assume that. *All* I'm talking about is olcott's
statement:
| When-so-ever a halt decider correctly determines that its input would
| never halt unless forced to halt by this halt decider this halt >>>>>>>>>>>>> | decider has made a correct not-halting determination.
I'm not trying to make it consistent with anything else olcott has >>>>>>>> written. DD() is irrelevant to what I'm talking about.
As I wrote before, let H be the "halt decider" and let I be its input >>>>>>>> (which represents a computation). I by itself does not halt. >>>>>>>> I-simulated-by-H may halt if H forces it to halt.
H might be a simulator, or it may just monitor the execution of I with >>>>>>>> the ability to halt it. H is not a pure simulator; it does not always
fully simulate the execution of I.
H is given the task of determining whether I is a halting computation or
not (a task that is not possible in all cases, but is certainly possible
in some cases).
Fair enough.
Your interpretation of Olcott's statement is indeed a tautology. That >>>>>>> tautology is not very interesting, and most people would interpret the >>>>>>> statement in the same as you (and me).
PO's interpretation of the statement is wrong, but that doesn't
interest you - he said the words and the words are correct in some >>>>>>> absolute sense even if PO does not understand that sense, and is >>>>>>> thinking of something different. PO made a true statement!
Interestingly, you're doing what PO does, sort of - he says the words >>>>>>> mean what /he/ says they mean, and that meaning justifies one of his >>>>>>> false claims. He supports this claim by saying Sipser agreed with the >>>>>>> words, even though it's clear Sipser's agreement was with a different >>>>>>> interpretation of those words.
<PO speaking>
But hey, Sipser "agreed with those words"! Sipser just didn't
appreciate the consequence of their true meaning [aka PO's
interpretation]. :)
</PO speaking>
[...]
So sure, you can say the statement is a tautology, but PO made that >>>>>>>>> statement and his interpretation of what it means is far from your >>>>>>>>> tautology.
Sure, he does that.
My overall point, I suppose, is that if people are going to argue with >>>>>>>> olcott, if he happens to make a true statement it's not helpful to argue
that its false.
I'm all for that - I'd go further to say that I champion that point of >>>>>>> view. But if PO makes a statement which he intends to mean XXX and XXX
is false, has he made a true statement just because your interpretation >>>>>>> of the same statement is YYY, different from XXX, and YYY happens to be >>>>>>> true?
In any case, I don't think anyone would disagree with your
interpretation of the statement being a tautology... Certainly not me.
(I think that's all that's to be said on this.)
Mike.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
Since it is an easily verified fact that DDD emulated
by HHH according to the rules of the x86 language
would never stop running unless aborted by HHH:
One cannot verify a statement that contains the word "would". That
word means that the statement refers to a counter-factual situation
but only factual situations can be verified.
But we can verify that DDD halts.
In other words you are a complete moron regarding
hypothetical possibilities. Being a complete moron
is not any actual rebuttal.
I'm not stupid enough to believe that we can learn about a counter- factual >>> hypotetical situation by looking at it and seeing what happens.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
Only one more that the number of recursions in the input.
That HHH aborts one cycle too early is a bug in HHH.
Op 26.mei.2025 om 22:28 schreef Richard Heathfield:
On 26/05/2025 20:35, Fred. Zwarts wrote:
Now DDD is not the caller of HHH
Yes, it is.
void DDD()
{
HHH(DDD);
return;
}
Only if we confuse levels of simulation.
int main () {
HHH(DDD);
}
Here main is the caller of HHH. In the first level of simulation DDD is simulated and calls HHH, which could cause a second level of simulation, where DDD is the caller, but that does not happen, because the first HHH aborts the simulation at that point. At the first (and only level), DDD
is not the caller of HHH. DDD is only the input to HHH, not the caller.
HHH should decide about its input, not about its caller.
DDD is, in fact, a pointer to memory. This memory includes the code of
DDD and all other code used by DDD, including the HHH that aborts. So,
the input specifies a halting program. But HHH does not see that part of
the specification, but aborts and makes the false assumption about
itself that it does not halt. This bug in HHH does not change the
verifiable fact that the input (not the caller) specifies a halting
program.
On 5/26/2025 2:14 PM, Richard Heathfield wrote:
On 26/05/2025 18:29, olcott wrote:
On 5/26/2025 12:25 PM, Richard Heathfield wrote:
On 26/05/2025 17:24, olcott wrote:
On 5/26/2025 11:10 AM, Richard Heathfield wrote:
On 26/05/2025 16:42, olcott wrote:
no
C function can see its own caller.
So because DDD calls HHH, HHH can't analyse the halting behaviour of DDD.
Got it.
I didn't say that.
Yes, you did.
On 24/5/2025 in Message-ID <100sr6o$ppn2$3@dont-email.me> you said:
You are a damned liar when you say that I said
that HHH must report on the behavior of its caller.
No HHH can report on the behavior of its caller
for the same reason that no function can report
on the value of the square-root of a dead cat.
Your words.
Since DDD is HHH's caller, according to you HHH can't report on DDD's
behaviour.
HHH(DDD) does correctly report on the behavior that its
input specifies.
It can't. Mr Olcott said so. (See above.) You /do/ believe him, right?
In other words you are pretending to be so stupid that
you don't know that the word *INPUT* and the word *CALLER*
are not the exact same word?
On 5/26/2025 4:43 AM, Mikko wrote:
On 2025-05-25 15:55:42 +0000, olcott said:
On 5/25/2025 5:19 AM, Richard Heathfield wrote:
On 24/05/2025 17:13, olcott wrote:
No HHH can report on the behavior of its caller
From Halt7.c:
void DDD()
{
HHH(DDD);
return;
}
Since (as you say) no HHH can report on the behaviour of its caller,
and since (as your code shows) DDD is HHH's caller, we deduce that HHH >>>> cannot report on DDD.
So HHH is not (according to you) a halt analyser for DDD.
I'm not sure you've left anything to discuss, have you?
HHH(DDD) does correctly reject
*ITS INPUT THUS NOT ITS CALLER*
as non-halting.
If the caller is DDD then the input specifies a halting behaviour because
DDD calls HHH with an input that specifies a halting behavour. But HHH
cannot correctly reject a halting input as non-halting.
The requirements of a halting decider cannot be met if the decider reports >> differently dependig on who calls it. Consequently, HHH is required to
return true also when the following FFF calls it:
void FFF(void) {
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
How many recursive emulations does HHH have to
wait before its emulated DDD magically halts
on its own without ever needing to be aborted?
On 5/26/2025 4:55 AM, Mikko wrote:
On 2025-05-25 14:32:14 +0000, olcott said:
On 5/25/2025 5:34 AM, Mikko wrote:
On 2025-05-24 17:15:50 +0000, olcott said:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves you're wrong >>>>>>Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus >>>>>> is true. Anybody putting up a contrary argument must therefore be wrong.
You might also put up a long winded argument why 2 + 2 = 5, and I would >>>>>> dismiss this likewise, without bothering to follow your exact detailed >>>>>> steps.
You've also tried, without success, to dismiss one of the proofs of the >>>>>> Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
People are successfull in pointing out errors in what you say.
When they point out errors it is always of this form:
"that is not the way that I memorized it".
If you were not lying you could point at least one pointer to a such
message. But you can't.
They never ever show any actual errors in my reasoning.
They do. For eample:
On Sat, 24 May 2025 17:07:11 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
When your opponents point to the Turing proof that proves you're wrong >>>Without going through all of the detailed steps that I present that is >>>> a reckless disregard for the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus >>> is true. Anybody putting up a contrary argument must therefore be
wrong.
That shows an actual error in your reasoning. You can't show any actual
error in Alan Mackenzie'sreasoning above.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The key mistake of the conventional halting problem proofs
is that they do not require the halt decider to report on
the actual behavior actually specified by the input.
When HHH(DDD) computes the mapping from its finite string
input to the behavior that it actually specifies, we see
that the emulated DDD will continue to call HHH(DDD) in
recursive emulation never able to reach its own emulated
"ret" instruction final halt state.
The recursive emulation invariant is that the emulated
DDD never reaches its own emulated "ret" instruction final
halt state.
Op 26.mei.2025 om 22:28 schreef Richard Heathfield:
On 26/05/2025 20:35, Fred. Zwarts wrote:
Now DDD is not the caller of HHH
Yes, it is.
void DDD()
{
HHH(DDD);
return;
}
Only if we confuse levels of simulation.
int main () {
HHH(DDD);
}
Here main is the caller of HHH.
In the first level of simulation
DDD is simulated and calls HHH, which could cause a second level
of simulation, where DDD is the caller, but that does not happen,
because the first HHH aborts the simulation at that point. At the
first (and only level), DDD is not the caller of HHH. DDD is only
the input to HHH, not the caller. HHH should decide about its
input, not about its caller.
DDD is, in fact, a pointer to memory. This memory includes the
code of DDD and all other code used by DDD, including the HHH
that aborts. So, the input specifies a halting program. But HHH
does not see that part of the specification, but aborts and makes
the false assumption about itself that it does not halt. This bug
in HHH does not change the verifiable fact that the input (not
the caller) specifies a halting program.
On 27/05/2025 09:48, Fred. Zwarts wrote:
Op 26.mei.2025 om 22:28 schreef Richard Heathfield:
On 26/05/2025 20:35, Fred. Zwarts wrote:
Now DDD is not the caller of HHH
Yes, it is.
void DDD()
{
HHH(DDD);
return;
}
Only if we confuse levels of simulation.
Only if we confuse terminology.
Noun
caller (plural callers)
(telephony) The person who makes a telephone call.
A visitor.
a gentleman caller
(bingo) The person who stands at the front of the hall and announces the numbers.
(programming) A function that calls another (the callee).
DDD calls HHH. Therefore DDD is the caller of HHH.
int main () {
HHH(DDD);
}
Here main is the caller of HHH.
Yes.
void DDD()
{
HHH(DDD);
return;
}
Here DDD is the caller of HHH.
HHH has (at least) two callers.
In the first level of simulation DDD is simulated and calls HHH, which
could cause a second level of simulation, where DDD is the caller, but
that does not happen, because the first HHH aborts the simulation at
that point. At the first (and only level), DDD is not the caller of
HHH. DDD is only the input to HHH, not the caller. HHH should decide
about its input, not about its caller.
DDD is, in fact, a pointer to memory. This memory includes the code of
DDD and all other code used by DDD, including the HHH that aborts. So,
the input specifies a halting program. But HHH does not see that part
of the specification, but aborts and makes the false assumption about
itself that it does not halt. This bug in HHH does not change the
verifiable fact that the input (not the caller) specifies a halting
program.
Understood, but you are only describing half the picture.
We can observe DDD's behaviour directly by calling it directly:
int main(void)
{
DDD();
}
Clearly this cannot change anything, because for simulation to be a
valid technique simulation must give the same result as direct
execution, and therefore direct execution must give the same result as simulation.
Here, it is even more abundantly clear than ever that DDD is the caller
of HHH. Since (according to Olcott) HHH cannot report on its caller, it cannot report on DDD.
Of course HHH can be called by any other function even by DDD.
But that is completely irrelevant
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I
understand your reasoning, but you and I are talking about different
things. My underlying point is quite simply that Olcott made an
incorrect and indeed contradictory claim about what HHH can and cannot
report on. At the very, *very* least he made an insufficiently
qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I
understand your reasoning, but you and I are talking about
different things. My underlying point is quite simply that
Olcott made an incorrect and indeed contradictory claim about
what HHH can and cannot report on. At the very, *very* least he
made an insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I
understand your reasoning, but you and I are talking about different
things. My underlying point is quite simply that Olcott made an
incorrect and indeed contradictory claim about what HHH can and cannot
report on. At the very, *very* least he made an insufficiently
qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the behavior of
its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on the behavior
that its input actually specifies" - so HHH must report on DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
On 5/26/2025 1:19 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:14 schreef olcott:
On 5/26/2025 4:55 AM, Mikko wrote:
On 2025-05-25 14:32:14 +0000, olcott said:
On 5/25/2025 5:34 AM, Mikko wrote:
On 2025-05-24 17:15:50 +0000, olcott said:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power.
When I provide the exact detailed steps of exactly how
people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that
loses defamation cases.
When your opponents point to the Turing proof that proves you're wrong
Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus
is true. Anybody putting up a contrary argument must therefore be wrong.
You might also put up a long winded argument why 2 + 2 = 5, and I would
dismiss this likewise, without bothering to follow your exact detailed >>>>>>>> steps.
You've also tried, without success, to dismiss one of the proofs of the
Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
People are successfull in pointing out errors in what you say.
When they point out errors it is always of this form:
"that is not the way that I memorized it".
If you were not lying you could point at least one pointer to a such
message. But you can't.
They never ever show any actual errors in my reasoning.
They do. For eample:
On Sat, 24 May 2025 17:07:11 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
When your opponents point to the Turing proof that proves you're wrong >>>>>Without going through all of the detailed steps that I present that is >>>>>> a reckless disregard for the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been proven, thus >>>>> is true. Anybody putting up a contrary argument must therefore be
wrong.
That shows an actual error in your reasoning. You can't show any actual >>>> error in Alan Mackenzie'sreasoning above.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The key mistake of the conventional halting problem proofs
is that they do not require the halt decider to report on
the actual behavior actually specified by the input.
They do. The input is a pointer to memory. This memory includes DDD and
all functions called by it directly and in directly, including the code
of Halt7.c, which specifies the abort, which makes that the input
specifies a halting program.
When HHH(DDD) computes the mapping from its finite string
input to the behavior that it actually specifies,
namely, a program that aborts and halts,
we see
that the emulated DDD will continue to call HHH(DDD) in
finite
recursive emulation
but unable to reach the emulated 'ret' instruction, because of a
premature abort. So, its mapping is incorrect, because it does not find
the behaviour that is actually specified. This bug makes that it is
never able to reach its own emulated
"ret" instruction final halt state.
The recursive emulation invariant is that the emulated
DDD never reaches its own emulated "ret" instruction final
halt state,
because it is aborted prematurely. This failure of HHH to reach the
'ret' instruction, does not change the specification in the input. It
only shows that the programmer made a mistake when he coded the abort
code.
Counter-factual.
DDD emulated by HHH1 calls HHH(DDD) and this call returns
DDD emulated by HHH calls HHH(DDD) and this call CANNOT POSSIBLY RETURN
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because
I understand your reasoning, but you and I are talking about
different things. My underlying point is quite simply that
Olcott made an incorrect and indeed contradictory claim about
what HHH can and cannot report on. At the very, *very* least
he made an insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on the
behavior that its input actually specifies" - so HHH must
report on DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting decider
cannot do what it must do. HHH is an example of that.
On 5/28/2025 2:46 AM, Richard Heathfield wrote:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because
I understand your reasoning, but you and I are talking about
different things. My underlying point is quite simply that
Olcott made an incorrect and indeed contradictory claim about
what HHH can and cannot report on. At the very, *very* least
he made an insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
It would be wrong if HHH did report on the behavior
of its caller. Functions computed by models of computation
are only allowed to compute the mapping from their inputs.
HHH's input is DDD, and you have said: "HHH must report on the
behavior that its input actually specifies" - so HHH must
report on DDD.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
On 5/28/2025 3:02 AM, Mikko wrote:
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it
because I understand your reasoning, but you and I are
talking about different things. My underlying point is quite
simply that Olcott made an incorrect and indeed
contradictory claim about what HHH can and cannot report on.
At the very, *very* least he made an insufficiently
qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on the
behavior that its input actually specifies" - so HHH must
report on DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting
decider
cannot do what it must do. HHH is an example of that.
We could make a requirement that the above sum(3,4) function
report on the sum of 5 + 6. This requirement would be incorrect.
We could make a requirement that a CAD system provides the
radius of a square circle, this requirement would be incorrect.
On 5/28/2025 10:02 AM, Richard Heathfield wrote:
On 28/05/2025 15:36, olcott wrote:
On 5/28/2025 2:46 AM, Richard Heathfield wrote:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by
DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it
because I understand your reasoning, but you and I are
talking about different things. My underlying point is
quite simply that Olcott made an incorrect and indeed
contradictory claim about what HHH can and cannot report
on. At the very, *very* least he made an insufficiently
qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
It would be wrong if HHH did report on the behavior
of its caller. Functions computed by models of computation
are only allowed to compute the mapping from their inputs.
So you're dead in the water.
HHH's input is DDD, and you have said: "HHH must report on
the behavior that its input actually specifies" - so HHH must
report on DDD.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
Fails to address my point, which is that you claim that HHH
cannot report on DDD and yet must report on DDD.
HHH must report on the actual behavior that its actual
input actually specifies. Framing the problem any other
way is incorrect.
When you require sum(3,4) to report on the sum of 5 + 6
YOU ARE WRONG. When you require HHH to report on the
behavior of its caller YOU ARE WRONG.
On 5/28/2025 4:44 AM, Richard Heathfield wrote:
On 28/05/2025 09:02, Mikko wrote:
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by
DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it
because I understand your reasoning, but you and I are
talking about different things. My underlying point is
quite simply that Olcott made an incorrect and indeed
contradictory claim about what HHH can and cannot report
on. At the very, *very* least he made an insufficiently
qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on
the behavior that its input actually specifies" - so HHH must
report on DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting
decider
cannot do what it must do. HHH is an example of that.
It is, but I'm not sure that Mr O will see it that way.
We can equally say that sum(3,4) must provide the sum of 5 + 6
and we would be wrong.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
In the conventional halting problem proof the answer
to the question:
What correct Boolean value can HHH(DD) return to
indicate the actual halt status of its input?
*BOTH BOOLEAN RETURN VALUES ARE INCORRECT*
When we understand that a STA must report on the
behavior that its input actually specifies we get
a different result.
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations thus HHH(DD) == 0 is correct.
On 5/28/2025 10:05 AM, Richard Heathfield wrote:
(a) "No HHH can report on the behavior of its caller"INCORRRECT
On 5/28/2025 10:23 AM, Richard Heathfield wrote:
On 28/05/2025 16:12, olcott wrote:
On 5/28/2025 4:44 AM, Richard Heathfield wrote:
On 28/05/2025 09:02, Mikko wrote:
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even
by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it
because I understand your reasoning, but you and I are
talking about different things. My underlying point is
quite simply that Olcott made an incorrect and indeed
contradictory claim about what HHH can and cannot report
on. At the very, *very* least he made an insufficiently
qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on
the behavior that its input actually specifies" - so HHH
must report on DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting
decider
cannot do what it must do. HHH is an example of that.
It is, but I'm not sure that Mr O will see it that way.
We can equally say that sum(3,4) must provide the sum of 5 + 6
and we would be wrong.
You have arrived at two contradictory requirements for your
system. Therefore, somewhere along the line you have made an
incorrect assumption.
5 + 6 isn't it.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
In the conventional halting problem proof the answer
to the question:
What correct Boolean value can HHH(DD) return to
indicate the actual halt status of its input?
*BOTH BOOLEAN RETURN VALUES ARE INCORRECT*
Not so.
The Halting Problem only says that if HHH is a universal
halting decider, which it clearly isn't.
In the conventional HP proof both Boolean
return values ARE THE WRONG ANSWER.
When we understand that a STA must report on the
behavior that its input actually specifies we get
a different result.
When you understand that you can't flannel your way past your
mutually contradictory requirements and recognise that they
indicate a break in your reasoning, we should get a different
result.
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations thus HHH(DD) == 0 is correct.
That's not the issue right now.
It is 100% of the whole issue.
I am not solving the halting problem.
Instead I proved that the conventional proof is wrong.
You keep getting confused about this.
On 5/28/2025 2:56 AM, Mikko wrote:It is not a tautology. It is a vacuous statement when the input does not
On 2025-05-26 18:30:19 +0000, olcott said:
On 5/26/2025 1:19 PM, Fred. Zwarts wrote:
Op 26.mei.2025 om 18:14 schreef olcott:
On 5/26/2025 4:55 AM, Mikko wrote:
On 2025-05-25 14:32:14 +0000, olcott said:
On 5/25/2025 5:34 AM, Mikko wrote:
On 2025-05-24 17:15:50 +0000, olcott said:
On 5/24/2025 12:07 PM, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:
On 23/05/2025 22:06, olcott wrote:
On 5/23/2025 3:50 PM, Richard Heathfield wrote:
On 23/05/2025 21:24, olcott wrote:
<snip>
Liar
An unequivocal response, but it lacks persuasive power. >>>>>>>>>>
When I provide the exact detailed steps of exactly how >>>>>>>>>>>>> people can show that I am wrong and they refuse to
show that I am wrong yet claim that I am wrong this
is the kind of reckless disregard for the truth that >>>>>>>>>>>>> loses defamation cases.
When your opponents point to the Turing proof that proves >>>>>>>>>>>> you're wrong
Without going through all of the detailed steps
that I present that is a reckless disregard for
the truth that loses defamation cases.
There you are utterly wrong. The Halting Theorem has been >>>>>>>>>> proven, thus
is true. Anybody putting up a contrary argument must
therefore be wrong.
You might also put up a long winded argument why 2 + 2 = 5, >>>>>>>>>> and I would
dismiss this likewise, without bothering to follow your exact >>>>>>>>>> detailed
steps.
You've also tried, without success, to dismiss one of the
proofs of the
Halting Therem as invalid.
And would be successful if people actually paid
attention to what I said.
People are successfull in pointing out errors in what you say.
When they point out errors it is always of this form:
"that is not the way that I memorized it".
If you were not lying you could point at least one pointer to a such >>>>>> message. But you can't.
They never ever show any actual errors in my reasoning.
They do. For eample:
On Sat, 24 May 2025 17:07:11 +0000, Alan Mackenzie wrote:
olcott <polcott333@gmail.com> wrote:
On 5/23/2025 5:06 PM, Richard Heathfield wrote:There you are utterly wrong. The Halting Theorem has been
On 23/05/2025 22:06, olcott wrote:
When your opponents point to the Turing proof that proves
you're wrong
Without going through all of the detailed steps that I present >>>>>>>> that is
a reckless disregard for the truth that loses defamation cases. >>>>>>>
proven, thus
is true. Anybody putting up a contrary argument must therefore be >>>>>>> wrong.
That shows an actual error in your reasoning. You can't show any
actual
error in Alan Mackenzie'sreasoning above.
void DDD()
{
HHH(DDD);
return;
}
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
The key mistake of the conventional halting problem proofs
is that they do not require the halt decider to report on
the actual behavior actually specified by the input.
They do. The input is a pointer to memory. This memory includes DDD
and all functions called by it directly and in directly, including
the code of Halt7.c, which specifies the abort, which makes that the
input specifies a halting program.
When HHH(DDD) computes the mapping from its finite string
input to the behavior that it actually specifies,
namely, a program that aborts and halts,
we see
that the emulated DDD will continue to call HHH(DDD) in
finite
recursive emulation
but unable to reach the emulated 'ret' instruction, because of a
premature abort. So, its mapping is incorrect, because it does not
find the behaviour that is actually specified. This bug makes that
it is
never able to reach its own emulated
"ret" instruction final halt state.
The recursive emulation invariant is that the emulated
DDD never reaches its own emulated "ret" instruction final
halt state,
because it is aborted prematurely. This failure of HHH to reach the
'ret' instruction, does not change the specification in the input.
It only shows that the programmer made a mistake when he coded the
abort code.
Counter-factual.
Nothing counter-factual in that paragraph.
DDD emulated by HHH1 calls HHH(DDD) and this call returns
DDD emulated by HHH calls HHH(DDD) and this call CANNOT POSSIBLY RETURN
That a call to HHH does not return is sufficient to conclude that
HHH is not a halt decider.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
On 5/28/2025 10:32 AM, Richard Heathfield wrote:
On 28/05/2025 16:17, olcott wrote:
On 5/28/2025 10:02 AM, Richard Heathfield wrote:
On 28/05/2025 15:36, olcott wrote:
On 5/28/2025 2:46 AM, Richard Heathfield wrote:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD. >>>>>>>>And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I >>>>>>>> understand your reasoning, but you and I are talking about
different things. My underlying point is quite simply that
Olcott made an incorrect and indeed contradictory claim about
what HHH can and cannot report on. At the very, *very* least he >>>>>>>> made an insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
It would be wrong if HHH did report on the behavior
of its caller. Functions computed by models of computation
are only allowed to compute the mapping from their inputs.
So you're dead in the water.
HHH's input is DDD, and you have said: "HHH must report on the
behavior that its input actually specifies" - so HHH must report
on DDD.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
Fails to address my point, which is that you claim that HHH cannot
report on DDD and yet must report on DDD.
HHH must report on the actual behavior that its actual
input actually specifies. Framing the problem any other
way is incorrect.
So you're saying that it must report on its input, which means that
HHH MUST report on its caller (because its caller /is/ its input).
Fine. Why didn't you say that to start with?
*This is ALL that HHH sees*
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
That some people expect HHH to report
on things that it does not see is stupid.
On 5/28/2025 3:28 PM, dbush wrote:
On 5/28/2025 4:24 PM, olcott wrote:
It is completely impossible to know with 100%
perfectly complete logical certainty that five
minutes ago ever exists.
That doesn't change the fact that I want to know if any
arbitrary algorithm X with input Y will halt when executed
directly.
That is *not* the way that reality actually works.
I think it's useful to know that trying to have any discussion with the
OP will eventually feel like nailing jelly to a wall.
On 5/28/2025 12:26 PM, Richard Heathfield wrote:
On 28/05/2025 16:51, olcott wrote:
On 5/28/2025 10:23 AM, Richard Heathfield wrote:
On 28/05/2025 16:12, olcott wrote:
On 5/28/2025 4:44 AM, Richard Heathfield wrote:
On 28/05/2025 09:02, Mikko wrote:
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD. >>>>>>>>>>And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I >>>>>>>>>> understand your reasoning, but you and I are talking about different >>>>>>>>>> things. My underlying point is quite simply that Olcott made an >>>>>>>>>> incorrect and indeed contradictory claim about what HHH can and cannot
report on. At the very, *very* least he made an insufficiently >>>>>>>>>> qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the behavior of
its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on the behavior
that its input actually specifies" - so HHH must report on DDD. >>>>>>>>
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting decider >>>>>>> cannot do what it must do. HHH is an example of that.
It is, but I'm not sure that Mr O will see it that way.
We can equally say that sum(3,4) must provide the sum of 5 + 6
and we would be wrong.
You have arrived at two contradictory requirements for your system.
Therefore, somewhere along the line you have made an incorrect
assumption.
5 + 6 isn't it.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
In the conventional halting problem proof the answer
to the question:
What correct Boolean value can HHH(DD) return to
indicate the actual halt status of its input?
*BOTH BOOLEAN RETURN VALUES ARE INCORRECT*
Not so.
The Halting Problem only says that if HHH is a universal halting
decider, which it clearly isn't.
In the conventional HP proof both Boolean
return values ARE THE WRONG ANSWER.
Only if you have a universal halting decider, which you don't.
When we understand that a STA must report on the
behavior that its input actually specifies we get
a different result.
When you understand that you can't flannel your way past your mutually >>>> contradictory requirements and recognise that they indicate a break in >>>> your reasoning, we should get a different result.
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations thus HHH(DD) == 0 is correct.
That's not the issue right now.
It is 100% of the whole issue.
Well, no. If anything, it raises a new issue (or at least an issue I
have yet to see you address), which is how you hope to distinguish
between a computation that never terminates and a computation that does
terminate after a very long time.
I am not solving the halting problem.
Instead I proved that the conventional proof is wrong.
On 5/28/2025 7:00 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 28/05/2025 18:33, olcott wrote:
I am not solving the halting problem.
Clearly.
But once upon a time he was. For example, in this exchange:
Me: Recent posts have said that you really do claim to have a halting
decider. Have you extended your claim or was that a
misunderstanding?
PO: I really do have a halting decider.
It took a very long time for me to understand
that a decider(CS) is not the common meaning of
anything that decides. A decider(CS) must be all
knowing.
On 5/28/2025 7:48 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 28/05/2025 18:33, olcott wrote:
I am not solving the halting problem.
Clearly.
But once upon a time he was. For example, in this exchange:
Me: Recent posts have said that you really do claim to have a halting
decider. Have you extended your claim or was that a
misunderstanding?
PO: I really do have a halting decider.
I think it's useful to know that trying to have any discussion with the
OP will eventually feel like nailing jelly to a wall.
Aug 10, 2020
https://groups.google.com/g/comp.theory/c/XRw3WhADb8I/m/JOwRQyV6BQAJ
Tarski undefinability can be easily dismissed once the
terms: "truthmaker" and "truthbearer" are fully understood.
On 5/28/2025 3:13 PM, dbush wrote:
On 5/28/2025 11:17 AM, olcott wrote:
When you require sum(3,4) to report on the sum of 5 + 6
YOU ARE WRONG. When you require HHH to report on the
behavior of its caller YOU ARE WRONG.
But I want to know what it's caller does.
In fact, I want to know if any arbitrary algorithm X with input Y will
halt when executed directly.
It is completely impossible to know with 100%
perfectly complete logical certainty that five
minutes ago ever exists.
On 5/28/2025 4:44 AM, Richard Heathfield wrote:
On 28/05/2025 09:02, Mikko wrote:
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I
understand your reasoning, but you and I are talking about
different things. My underlying point is quite simply that Olcott
made an incorrect and indeed contradictory claim about what HHH
can and cannot report on. At the very, *very* least he made an
insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the behavior
of its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on the
behavior that its input actually specifies" - so HHH must report on
DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting decider
cannot do what it must do. HHH is an example of that.
It is, but I'm not sure that Mr O will see it that way.
We can equally say that sum(3,4) must provide the sum of 5 + 6
and we would be wrong.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
In the conventional halting problem proof the answer
to the question:
What correct Boolean value can HHH(DD) return to
indicate the actual halt status of its input?
*BOTH BOOLEAN RETURN VALUES ARE INCORRECT*
When we understand that a STA must report on the
behavior that its input actually specifies we get
a different result.
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations thus HHH(DD) == 0 is correct.
On 5/28/2025 7:48 PM, Keith Thompson wrote:
Ben Bacarisse <ben@bsb.me.uk> writes:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 28/05/2025 18:33, olcott wrote:
I am not solving the halting problem.
Clearly.
But once upon a time he was. For example, in this exchange:
Me: Recent posts have said that you really do claim to have a halting
decider. Have you extended your claim or was that a
misunderstanding?
PO: I really do have a halting decider.
I think it's useful to know that trying to have any discussion with the
OP will eventually feel like nailing jelly to a wall.
Aug 10, 2020
https://groups.google.com/g/comp.theory/c/XRw3WhADb8I/m/JOwRQyV6BQAJ
Tarski undefinability can be easily dismissed once the
terms: "truthmaker" and "truthbearer" are fully understood.
14 Every epistemological antinomy can likewise be used for a similar undecidability proof. (Gödel 1931:39-41)
As soon as one is fully away that epistemological antinomies
are simply not truth bearers and thus must be rejected on
this basis the Gödel and Tarski proofs utterly cease to function.
On 5/28/2025 12:26 PM, Richard Heathfield wrote:
On 28/05/2025 16:51, olcott wrote:
On 5/28/2025 10:23 AM, Richard Heathfield wrote:
On 28/05/2025 16:12, olcott wrote:
On 5/28/2025 4:44 AM, Richard Heathfield wrote:
On 28/05/2025 09:02, Mikko wrote:
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD. >>>>>>>>>>And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because >>>>>>>>>> I understand your reasoning, but you and I are talking about >>>>>>>>>> different things. My underlying point is quite simply that >>>>>>>>>> Olcott made an incorrect and indeed contradictory claim about >>>>>>>>>> what HHH can and cannot report on. At the very, *very* least >>>>>>>>>> he made an insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on the >>>>>>>> behavior that its input actually specifies" - so HHH must report >>>>>>>> on DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting decider >>>>>>> cannot do what it must do. HHH is an example of that.
It is, but I'm not sure that Mr O will see it that way.
We can equally say that sum(3,4) must provide the sum of 5 + 6
and we would be wrong.
You have arrived at two contradictory requirements for your system.
Therefore, somewhere along the line you have made an incorrect
assumption.
5 + 6 isn't it.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
In the conventional halting problem proof the answer
to the question:
What correct Boolean value can HHH(DD) return to
indicate the actual halt status of its input?
*BOTH BOOLEAN RETURN VALUES ARE INCORRECT*
Not so.
The Halting Problem only says that if HHH is a universal halting
decider, which it clearly isn't.
In the conventional HP proof both Boolean
return values ARE THE WRONG ANSWER.
Only if you have a universal halting decider, which you don't.
When we understand that a STA must report on the
behavior that its input actually specifies we get
a different result.
When you understand that you can't flannel your way past your
mutually contradictory requirements and recognise that they indicate
a break in your reasoning, we should get a different result.
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations thus HHH(DD) == 0 is correct.
That's not the issue right now.
It is 100% of the whole issue.
Well, no. If anything, it raises a new issue (or at least an issue I
have yet to see you address), which is how you hope to distinguish
between a computation that never terminates and a computation that
does terminate after a very long time.
I am not solving the halting problem.
Instead I proved that the conventional proof is wrong.
You keep getting confused about this.
It seems to me that your HHH would abort them both and report them
both as non-terminating, which would be correct for only one of them.
On 5/28/2025 7:00 PM, Ben Bacarisse wrote:
Richard Heathfield <rjh@cpax.org.uk> writes:
On 28/05/2025 18:33, olcott wrote:
I am not solving the halting problem.
Clearly.
But once upon a time he was. For example, in this exchange:
Me: Recent posts have said that you really do claim to have a halting
decider. Have you extended your claim or was that a
misunderstanding?
PO: I really do have a halting decider.
It took a very long time for me to understand
that a decider(CS) is not the common meaning of
anything that decides. A decider(CS) must be all
knowing.
Whenever I use any term I am always referring
to its common meaning.
I think it's useful to know that trying to have any discussion with the
OP will eventually feel like nailing jelly to a wall.
Yet you fail to give me an honest dialogue.
On 5/28/2025 10:05 AM, Richard Heathfield wrote:
On 28/05/2025 15:43, olcott wrote:INCORRRECT
On 5/28/2025 3:02 AM, Mikko wrote:
On 2025-05-28 07:46:42 +0000, Richard Heathfield said:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I
understand your reasoning, but you and I are talking about
different things. My underlying point is quite simply that Olcott >>>>>>> made an incorrect and indeed contradictory claim about what HHH
can and cannot report on. At the very, *very* least he made an
insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the
behavior of its caller" - so HHH cannot report on DDD.
HHH's input is DDD, and you have said: "HHH must report on the
behavior that its input actually specifies" - so HHH must report on
DDD.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
Why not? The point of the halting theorem is that a halting decider
cannot do what it must do. HHH is an example of that.
We could make a requirement that the above sum(3,4) function
report on the sum of 5 + 6. This requirement would be incorrect.
We could make a requirement that a CAD system provides the
radius of a square circle, this requirement would be incorrect.
Which of your requirements are you now claiming to be incorrect?
(a) "No HHH can report on the behavior of its caller"
(b) "HHH must report on the behavior that its input actually specifies"CORRECT
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
On 5/28/2025 2:46 AM, Richard Heathfield wrote:
On 27/05/2025 22:25, olcott wrote:
On 5/27/2025 8:11 AM, Richard Heathfield wrote:
On 27/05/2025 11:41, Fred. Zwarts wrote:
<snip>
Of course HHH can be called by any other function even by DDD.
And is. DDD's source shows this.
But that is completely irrelevant
Not in my view.
I accept that that's your view and I won't dispute it because I
understand your reasoning, but you and I are talking about different
things. My underlying point is quite simply that Olcott made an
incorrect and indeed contradictory claim about what HHH can and
cannot report on. At the very, *very* least he made an
insufficiently qualified claim.
int sum(int x, int y) { return x + y; }
HHH must report on the behavior that its input actually
specifies the same way that sum(3,4) must report on the
sum of 3 + 4.
DDD calls HHH, and you have said: "No HHH can report on the behavior
of its caller" - so HHH cannot report on DDD.
It would be wrong if HHH did report on the behavior
of its caller. Functions computed by models of computation
are only allowed to compute the mapping from their inputs.
HHH's input is DDD, and you have said: "HHH must report on the
behavior that its input actually specifies" - so HHH must report on DDD.
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
Size in bytes:(0018) [000021a3]
It is a tautology that every input to a simulating
termination analyzer would never stop running unless
aborted specifies a non-terminating sequence of
configurations.
Cannot/must.
Must/cannot.
Surely you don't really expect us to take you seriously?
On 5/28/2025 3:13 PM, dbush wrote:
On 5/28/2025 11:17 AM, olcott wrote:
When you require sum(3,4) to report on the sum of 5 + 6
YOU ARE WRONG. When you require HHH to report on the
behavior of its caller YOU ARE WRONG.
But I want to know what it's caller does.
In fact, I want to know if any arbitrary algorithm X with input Y will
halt when executed directly.
It is completely impossible to know with 100%
perfectly complete logical certainty that five
minutes ago ever exists.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 493 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 170:33:09 |
| Calls: | 9,704 |
| Calls today: | 4 |
| Files: | 13,736 |
| Messages: | 6,178,354 |