On 5/13/2025 12:01 PM, olcott wrote:
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we
want to know about.
On 5/13/2025 1:06 PM, Richard Heathfield wrote:
On 13/05/2025 17:21, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
<snip>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that
we want to know about.
Why?
DDD doesn't do anything interesting.
I wasn't referring to DDD specifically, but in general.
He's claiming *in general* that H(X) is supposed to report on "X
simulated by H" instead of the direct execution of X,
On 13/05/2025 18:12, dbush wrote:
On 5/13/2025 1:06 PM, Richard Heathfield wrote:
On 13/05/2025 17:21, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
<snip>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we want to know about.
Why?
DDD doesn't do anything interesting.
I wasn't referring to DDD specifically, but in general.
He's claiming *in general* that H(X) is supposed to report on "X simulated by H" instead of the
direct execution of X,
...where the former is obviously less interesting than the latter. Fair enough.
<snip>
On 5/13/2025 12:06 PM, Richard Heathfield wrote:
On 13/05/2025 17:21, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
<snip>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that
we want to know about.
Why?
DDD doesn't do anything interesting.
If it were a universal halt decider we'd have a reason to care,
because its very existence would overturn pretty much the whole
of computability theory and enable us to clean up many of the
unsolved problems of mathematics.
Sure and we could achieve the same thing by
simply hard-coding the actual all-knowing
mind of God into a formal system.
The question is not about any universal halt
decider
that must be literally all knowing.
It has always actually only been about things
that could prevent consistently determining
the halt status of conventional programs.
But it /isn't/ a universal halt decider, so who (apart from Mr
Olcott) gives a damn whether it stops? About the only reason I
can think of for caring is to set Mr Olcott straight, but he
has made it abundantly clear that he's unsettable straightable.
There is no time that we are ever going to directly
encode omniscience into a computer program.
The
screwy idea of a universal halt decider that is
literally ALL KNOWING is just a screwy idea.
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. It
seems there are only about 2 or 3 actual variations of what PO is
saying and all the rest is several thousand repeats by both PO and >>>>>> responders...
Those who insist on responding to Olcott (of which I admit I have
occasionally been one despite my better intuitions) would be well
advised to adopt something like the rule of ko (in the game go)
which prohibits one from returning to the exact same position.
Simply repeating the same objection after olcott has ignored it is
pointless. If he didn't get the objection the fiftieth time he's
not going to get it the fifty-first time either.
If people adopted this policy most of the threads on this forum
would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his
dreams, he would see that his key points have been addresses and
refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
*DD emulated by HHH according to*
*the rules of the x86 language*
has never been explained. The closest thing to
reasoning that was provided on this point is
"that is what textbooks say".
On 5/13/2025 11:21 AM, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. It >>>>>>>> seems there are only about 2 or 3 actual variations of what PO >>>>>>>> is saying and all the rest is several thousand repeats by both >>>>>>>> PO and responders...
Those who insist on responding to Olcott (of which I admit I have >>>>>>> occasionally been one despite my better intuitions) would be well >>>>>>> advised to adopt something like the rule of ko (in the game go)
which prohibits one from returning to the exact same position.
Simply repeating the same objection after olcott has ignored it
is pointless. If he didn't get the objection the fiftieth time
he's not going to get it the fifty-first time either.
If people adopted this policy most of the threads on this forum
would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his
dreams, he would see that his key points have been addresses and
refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we want
to know about.
Just like naive set theory wanted to know
about Russell's Paradox until ZFC came along
and ruled that questions about Russell's Paradox
are based on an incorrect notion of set theory.
The behavior of "HHH simulated by DD" is just not something that
anyone cares about.
An H that tells us if any algorithm X with input Y can solve the
Goldbach conjecture and make unknowable truths knowable.
An H that tell us if "H simulated by DD" halts doesn't tell us that.
On 5/13/2025 12:09 PM, dbush wrote:
On 5/13/2025 12:56 PM, olcott wrote:
On 5/13/2025 11:21 AM, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. >>>>>>>>>> It seems there are only about 2 or 3 actual variations of what >>>>>>>>>> PO is saying and all the rest is several thousand repeats by >>>>>>>>>> both PO and responders...
Those who insist on responding to Olcott (of which I admit I >>>>>>>>> have occasionally been one despite my better intuitions) would >>>>>>>>> be well advised to adopt something like the rule of ko (in the >>>>>>>>> game go) which prohibits one from returning to the exact same >>>>>>>>> position. Simply repeating the same objection after olcott has >>>>>>>>> ignored it is pointless. If he didn't get the objection the
fiftieth time he's not going to get it the fifty-first time
either.
If people adopted this policy most of the threads on this forum >>>>>>>>> would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his
dreams, he would see that his key points have been addresses and >>>>>>> refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we want
to know about.
Just like naive set theory wanted to know
about Russell's Paradox until ZFC came along
and ruled that questions about Russell's Paradox
are based on an incorrect notion of set theory.
But unlike Russell's Paradox, there's nothing wrong with the fact that
a halt decider doesn't exist.
Sure there is. A halt decider doesn't exist
for the same reason that the set of all sets
that do not contain themselves does not exist.
*As defined both were simply wrong-headed ideas*
On 5/13/2025 10:28 PM, dbush wrote:
On 5/13/2025 11:06 PM, olcott wrote:
On 5/13/2025 9:44 PM, dbush wrote:
On 5/13/2025 10:41 PM, olcott wrote:
On 5/13/2025 8:56 PM, dbush wrote:
On 5/13/2025 9:52 PM, olcott wrote:
On 5/13/2025 8:38 PM, dbush wrote:
On 5/13/2025 9:35 PM, olcott wrote:
On 5/13/2025 8:26 PM, dbush wrote:
On 5/13/2025 9:16 PM, olcott wrote:
On 5/13/2025 8:03 PM, dbush wrote:
Nope. Russell's Paradox was derived from the base
axioms of naive set theory, proving the whole system
was inconsistent.
In contrast, there is nothing in existing computation
theory that requires that a halt decider exists.
I see you made no attempt to refute the above
statement. Unless you can show from the axioms of
computation theory that the following requirements can
be met, your argument has no basis:
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
A halt decider doesn't exist
for the same reason that the set of all sets
that do not contain themselves does not exist.
*As defined both were simply wrong-headed ideas*
There's nothing wrong-headed about wanting to know if
any arbitrary algorithm X with input Y will halt when
executed directly.
Yes there is. I have proven this countless times.
That requirements are impossible to satisfy doesn't
make them wrong. It just makes them impossible to
satisfy, which is a perfectly reasonable conclusion.
It did with Russell's Paradox.
ZFC rejected the whole foundation upon which
RP was built.
ZFC did not solve some other Russell's Paradox
it rejected the whole idea of RP as nonsense.
Unless you can show from the axioms of computation theory
that the following requirements can be met, your argument
has no basis:
Alternatively I can do what ZFC did and over-rule
the whole foundation upon which the HP proofs are build.
You mean the assumption that the following requirements
(which are *not* part of the axioms of computation theory)
can be satisfied? The assumption that Linz and other proved
was false and that you *explicitly* agreed with?
The conventional halting problem proofs have your
requirements as its foundation.
They have the *assumption* that the requirements can be met,
and via proof by contradiction show the assumption to be false.
And the fact that the requirements can't be met is fine, just
like the the fact that these requirements can't be met is fine:
A mythic number is a number N such that N > 5 and N < 2.
We can also say that no computation can compute
the square root of a dead rabbit. In none of these
cases is computation actually limited.
We could equally say that no whale can give
birth to a pigeon. This places no actual limit
on the behavior of whales. Whales were never
meant to give birth to pigeons.
And as was said before:
On 5/5/2025 5:39 PM, olcott wrote:
On 5/5/2025 4:31 PM, dbush wrote:but the
Strawman. The square root of a dead rabbit does not exist,
halts whenquestion of whether any arbitrary algorithm X with input Y
executed directly has a correct answer in all cases.;
;
It has a correct answer that cannot ever be computed
This qualifies as both a non-rebuttal and your confirmation you
agree that Linz and others are correct that no algorithm exists
that satisfies the below requirements:
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
It is true that a TM either halts or does not halt.
None-the-less the above requirements simply ignore
that some inputs specify behavior that differs
from the behavior of their direct execution.
It is stupidly wrong to REQUIRE a correct sum()
function to require sum(3,2) to report the sum of 5 + 7.
On 5/13/2025 11:43 PM, Richard Heathfield wrote:<snip>
Mr Olcott's response to this appears to be that we should allow
H to set aside impossible inputs in the pursuit of some kind of
meaningful answer.
What he fails to notice is that it isn't necessary to set
impossible inputs aside. Why not? Because they're impossible.
Incorrect requirements are possible when they
conflict with other requirements.
On 5/14/2025 12:02 AM, Richard Heathfield wrote:
On 14/05/2025 05:54, olcott wrote:
Incorrect requirements are possible when they
conflict with other requirements.
There is no requirement and no conflict. H cannot exist, and
therefore no requirements (other than non-existence) can be
imposed upon it.
H does exist when its goal is defined coherently
On 5/13/2025 1:20 PM, Mike Terry wrote:
On 13/05/2025 19:00, Richard Heathfield wrote:
On 13/05/2025 18:12, dbush wrote:
On 5/13/2025 1:06 PM, Richard Heathfield wrote:
On 13/05/2025 17:21, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
<snip>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we
want to know about.
Why?
DDD doesn't do anything interesting.
I wasn't referring to DDD specifically, but in general.
He's claiming *in general* that H(X) is supposed to report on "X
simulated by H" instead of the direct execution of X,
...where the former is obviously less interesting than the latter.
Fair enough.
<snip>
Right! PO's defintion of PO-halting (based on what "the simulator"
does) makes halting a property of both the input being decided /and/
the machine doing the deciding.
Real halting is a property of just the input being decided, as is
The input being decided by HHH(DD) includes DD
calling its own emulator in recursive simulation.
On 5/13/2025 11:01 AM, olcott wrote:
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. It >>>>>>> seems there are only about 2 or 3 actual variations of what PO is >>>>>>> saying and all the rest is several thousand repeats by both PO
and responders...
Those who insist on responding to Olcott (of which I admit I have
occasionally been one despite my better intuitions) would be well
advised to adopt something like the rule of ko (in the game go)
which prohibits one from returning to the exact same position.
Simply repeating the same objection after olcott has ignored it is >>>>>> pointless. If he didn't get the objection the fiftieth time he's
not going to get it the fifty-first time either.
If people adopted this policy most of the threads on this forum
would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his
dreams, he would see that his key points have been addresses and
refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
*DD emulated by HHH according to*
*the rules of the x86 language*
has never been explained. The closest thing to
reasoning that was provided on this point is
"that is what textbooks say".
ZFC reformulated set theory correcting its error
and the original set theory is now called naive
set theory.
When we understand that a termination analyzer
must compute the mapping from its input to the
behavior that this input actually specifies
then all of the conventional halting problem
proof fail.
How does it make sense to require a termination
analyzer to report on behavior that is not the
actual behavior that the input specifies?
Mike seems to have indicated that this has
been explained in full and I simply ignored
the explanation.
On 5/13/2025 4:28 PM, Richard Heathfield wrote:No, HHH computes the wrong mapping by skipping the most important part
On 13/05/2025 22:16, olcott wrote:
On 5/13/2025 12:06 PM, Richard Heathfield wrote:
On 13/05/2025 17:21, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
<snip>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we
want to know about.
Why?
DDD doesn't do anything interesting.
If it were a universal halt decider we'd have a reason to care,
because its very existence would overturn pretty much the whole of
computability theory and enable us to clean up many of the unsolved
problems of mathematics.
Sure and we could achieve the same thing by
simply hard-coding the actual all-knowing
mind of God into a formal system.
No, we couldn't.
The question is not about any universal halt
decider
Yes, it is.
that must be literally all knowing.
That sounds like hyperbole, but it's actually not far off. It could,
at least, be used as an oracle; you'd just need to find a way to
express your question as a YNA program.
It has always actually only been about things
that could prevent consistently determining
the halt status of conventional programs.
No, it's all about demonstrating that some computational problems
can't be solved. The whole halting thing is just a vehicle that can be
used as an example of an undecidable computation.
In cannot include things that humanity has no knowledge of
such as the Goldbach's conjecture and the meaning of life.
The time is quickly coming when AI will be thousands-fold
smarter than the smartest human. Such as AI might figure
out the Goldbach's conjecture.
But it /isn't/ a universal halt decider, so who (apart from Mr
Olcott) gives a damn whether it stops? About the only reason I can
think of for caring is to set Mr Olcott straight, but he has made it
abundantly clear that he's unsettable straightable.
There is no time that we are ever going to directly
encode omniscience into a computer program.
Right.
The
screwy idea of a universal halt decider that is
literally ALL KNOWING is just a screwy idea.
There's nothing screwy about proving that such a program can't be
written.
Requiring it to be ALL KNOWING was always a little nuts.
Requiring it to get fooled on fewer and fewer inputs
is the rational goal.
HHH does compute the mapping from its input
finite string to the behavior that this finite
string specifies and this includes HHH emulating
itself emulating DDD.
On 5/13/2025 10:48 PM, dbush wrote:
On 5/13/2025 11:38 PM, olcott wrote:
On 5/13/2025 10:28 PM, dbush wrote:
On 5/13/2025 11:06 PM, olcott wrote:
On 5/13/2025 9:44 PM, dbush wrote:
On 5/13/2025 10:41 PM, olcott wrote:
On 5/13/2025 8:56 PM, dbush wrote:
On 5/13/2025 9:52 PM, olcott wrote:
On 5/13/2025 8:38 PM, dbush wrote:
On 5/13/2025 9:35 PM, olcott wrote:
On 5/13/2025 8:26 PM, dbush wrote:
On 5/13/2025 9:16 PM, olcott wrote:
On 5/13/2025 8:03 PM, dbush wrote:
Nope. Russell's Paradox was derived from the base axioms >>>>>>>>>>>>>> of naive set theory, proving the whole system was
inconsistent.
In contrast, there is nothing in existing computation >>>>>>>>>>>>>> theory that requires that a halt decider exists.
I see you made no attempt to refute the above statement. >>>>>>>>>>>> Unless you can show from the axioms of computation theory >>>>>>>>>>>> that the following requirements can be met, your argument >>>>>>>>>>>> has no basis:
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
A halt decider doesn't exist
for the same reason that the set of all sets
that do not contain themselves does not exist.
*As defined both were simply wrong-headed ideas*
There's nothing wrong-headed about wanting to know if any >>>>>>>>>>>>>> arbitrary algorithm X with input Y will halt when executed >>>>>>>>>>>>>> directly.
Yes there is. I have proven this countless times.
That requirements are impossible to satisfy doesn't make >>>>>>>>>>>> them wrong. It just makes them impossible to satisfy, which >>>>>>>>>>>> is a perfectly reasonable conclusion.
It did with Russell's Paradox.
ZFC rejected the whole foundation upon which
RP was built.
ZFC did not solve some other Russell's Paradox
it rejected the whole idea of RP as nonsense.
Unless you can show from the axioms of computation theory that >>>>>>>>>> the following requirements can be met, your argument has no >>>>>>>>>> basis:
Alternatively I can do what ZFC did and over-rule
the whole foundation upon which the HP proofs are build.
You mean the assumption that the following requirements (which >>>>>>>> are *not* part of the axioms of computation theory) can be
satisfied? The assumption that Linz and other proved was false >>>>>>>> and that you *explicitly* agreed with?
The conventional halting problem proofs have your
requirements as its foundation.
They have the *assumption* that the requirements can be met, and
via proof by contradiction show the assumption to be false.
And the fact that the requirements can't be met is fine, just like >>>>>> the the fact that these requirements can't be met is fine:
A mythic number is a number N such that N > 5 and N < 2.
We can also say that no computation can compute
the square root of a dead rabbit. In none of these
cases is computation actually limited.
We could equally say that no whale can give
birth to a pigeon. This places no actual limit
on the behavior of whales. Whales were never
meant to give birth to pigeons.
And as was said before:
On 5/5/2025 5:39 PM, olcott wrote:
On 5/5/2025 4:31 PM, dbush wrote:when
Strawman. The square root of a dead rabbit does not exist, but the >>>> >> question of whether any arbitrary algorithm X with input Y halts
executed directly has a correct answer in all cases.;
;
It has a correct answer that cannot ever be computed
This qualifies as both a non-rebuttal and your confirmation you
agree that Linz and others are correct that no algorithm exists that
satisfies the below requirements:
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
It is true that a TM either halts or does not halt.
None-the-less the above requirements simply ignore
that some inputs specify behavior that differs
from the behavior of their direct execution.
What you think the input specifies is irrelevant.
What it actually specifies rules the computation.
On 5/13/2025 8:03 PM, dbush wrote:
On 5/13/2025 5:09 PM, olcott wrote:
On 5/13/2025 12:09 PM, dbush wrote:
On 5/13/2025 12:56 PM, olcott wrote:
On 5/13/2025 11:21 AM, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. >>>>>>>>>>>> It seems there are only about 2 or 3 actual variations of >>>>>>>>>>>> what PO is saying and all the rest is several thousand >>>>>>>>>>>> repeats by both PO and responders...
Those who insist on responding to Olcott (of which I admit I >>>>>>>>>>> have occasionally been one despite my better intuitions) >>>>>>>>>>> would be well advised to adopt something like the rule of ko >>>>>>>>>>> (in the game go) which prohibits one from returning to the >>>>>>>>>>> exact same position. Simply repeating the same objection >>>>>>>>>>> after olcott has ignored it is pointless. If he didn't get >>>>>>>>>>> the objection the fiftieth time he's not going to get it the >>>>>>>>>>> fifty-first time either.
If people adopted this policy most of the threads on this >>>>>>>>>>> forum would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his >>>>>>>>> dreams, he would see that his key points have been addresses >>>>>>>>> and refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we
want to know about.
Just like naive set theory wanted to know
about Russell's Paradox until ZFC came along
and ruled that questions about Russell's Paradox
are based on an incorrect notion of set theory.
But unlike Russell's Paradox, there's nothing wrong with the fact
that a halt decider doesn't exist.
Sure there is.
Nope. Russell's Paradox was derived from the base axioms of naive set
theory, proving the whole system was inconsistent.
In contrast, there is nothing in existing computation theory that
requires that a halt decider exists.
A halt decider doesn't exist
for the same reason that the set of all sets
that do not contain themselves does not exist.
*As defined both were simply wrong-headed ideas*
There's nothing wrong-headed about wanting to know if any arbitrary
algorithm X with input Y will halt when executed directly.
Yes there is. I have proven this countless times.
You ignore this because you are indoctrinated not
because you have any actual reasoning showing that
I am wrong.
int sum(int x, int y) { return x + y; }
Requiring HHH to report on behavior other than the
behavior that its input specifies is exactly stupidly
the same thing as requiring the above sum() function
to report the sum of 5 + 7 for sum(3,2).
YOU NEVER THINK IT THROUGH YOU MERELY CONTINUE
TO BASELESSLY SAY THAT I AM WRONG.
On 5/13/2025 12:06 PM, Richard Heathfield wrote:
On 13/05/2025 17:21, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
<snip>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we want
to know about.
Why?
DDD doesn't do anything interesting.
If it were a universal halt decider we'd have a reason to care,
because its very existence would overturn pretty much the whole of
computability theory and enable us to clean up many of the unsolved
problems of mathematics.
Sure and we could achieve the same thing by
simply hard-coding the actual all-knowing
mind of God into a formal system.
The question is not about any universal halt
decider that must be literally all knowing.
It has always actually only been about things
that could prevent consistently determining
the halt status of conventional programs.
But it /isn't/ a universal halt decider, so who (apart from Mr Olcott)
gives a damn whether it stops? About the only reason I can think of
for caring is to set Mr Olcott straight, but he has made it abundantly
clear that he's unsettable straightable.
There is no time that we are ever going to directly
encode omniscience into a computer program. The
screwy idea of a universal halt decider that is
literally ALL KNOWING is just a screwy idea.
On 5/13/2025 1:20 PM, Mike Terry wrote:
On 13/05/2025 19:00, Richard Heathfield wrote:
On 13/05/2025 18:12, dbush wrote:
On 5/13/2025 1:06 PM, Richard Heathfield wrote:
On 13/05/2025 17:21, dbush wrote:
On 5/13/2025 12:01 PM, olcott wrote:
<snip>
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
Quite simply, it's the behavior of the direct execution that we
want to know about.
Why?
DDD doesn't do anything interesting.
I wasn't referring to DDD specifically, but in general.
He's claiming *in general* that H(X) is supposed to report on "X
simulated by H" instead of the direct execution of X,
...where the former is obviously less interesting than the latter.
Fair enough.
<snip>
Right! PO's defintion of PO-halting (based on what "the simulator"
does) makes halting a property of both the input being decided /and/
the machine doing the deciding.
Real halting is a property of just the input being decided, as is
The input being decided by HHH(DD) includes DD
calling its own emulator in recursive simulation.
The input being decided by HHH1(DD) DOES NOT INCLUDE
DD calling its own emulator in recursive simulation.
required to be the case with any "decision problem" such as HP. His
definition is a total non-starter. That's before we even point out
that an input for HP doesn't even have "its simulator" in general.
Mike.
On 5/13/2025 11:01 AM, olcott wrote:
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. It >>>>>>> seems there are only about 2 or 3 actual variations of what PO is >>>>>>> saying and all the rest is several thousand repeats by both PO
and responders...
Those who insist on responding to Olcott (of which I admit I have
occasionally been one despite my better intuitions) would be well
advised to adopt something like the rule of ko (in the game go)
which prohibits one from returning to the exact same position.
Simply repeating the same objection after olcott has ignored it is >>>>>> pointless. If he didn't get the objection the fiftieth time he's
not going to get it the fifty-first time either.
If people adopted this policy most of the threads on this forum
would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his
dreams, he would see that his key points have been addresses and
refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
*DD emulated by HHH according to*
*the rules of the x86 language*
has never been explained. The closest thing to
reasoning that was provided on this point is
"that is what textbooks say".
ZFC reformulated set theory correcting its error
and the original set theory is now called naive
set theory.
When we understand that a termination analyzer
must compute the mapping from its input to the
behavior that this input actually specifies
then all of the conventional halting problem
proof fail.
How does it make sense to require a termination
analyzer to report on behavior that is not the
actual behavior that the input specifies?
Mike seems to have indicated that this has
been explained in full and I simply ignored
the explanation.
It is nuts to propose the idea of a universal
halt decider when we know that there are some
things that can only be decided by an infinite
computation.
The HP proofs require an input D that can actually
do the opposite of whatever value that H returns.
Such an input cannot possibly exist.
A halt decider is certainly not required to report
On 5/14/2025 11:16 AM, Richard Heathfield wrote:
On 14/05/2025 17:04, olcott wrote:
<snip>
The HP proofs require an input D that can actually
do the opposite of whatever value that H returns.
Such an input cannot possibly exist.
Agreed. That is precisely what Turing proved.
You did not pay enough attention.
The proof itself cannot exist because it is
missing a key element.
On 5/14/2025 10:44 AM, Richard Heathfield wrote:
On 14/05/2025 16:32, olcott wrote:
<snip>
It is nuts to propose the idea of a universal
halt decider when we know that there are some
things that can only be decided by an infinite
computation.
It is precisely because Alan Turing proposed the idea of a
universal halt decider that we know that there are some things
that can only be decided by an infinite computation.
That has nothing to do with any of the
conventional proofs that the halting
problem has no solution.
It is never "yes it can be done in an infinite number of steps"
On 5/14/2025 12:15 PM, Richard Heathfield wrote:<snip>
On 14/05/2025 17:43, olcott wrote:
The proof itself cannot exist because it is
missing a key element.
The proof exists. Check the literature. It's complete, and it's
not missing anything.
You INSIST on not paying enough attention.
When you try to encode *AN INPUT* that actually
does the opposite of whatever value that
its termination analyzer returns in a fully
specified language such as C you will find
this is impossible.
On 5/14/2025 12:41 PM, Richard Heathfield wrote:
When you try to encode *A PROGRAM* that actually computes for
arbitrary program P
I have never been talking about that at any time
in the last five years.
PAY ATTENTION !!!
On 5/14/2025 11:16 AM, Richard Heathfield wrote:No, you were right: D cannot exist without H.
On 14/05/2025 17:04, olcott wrote:The proof itself cannot exist because it is missing a key element.
The HP proofs require an input D that can actually do the opposite ofAgreed. That is precisely what Turing proved.
whatever value that H returns. Such an input cannot possibly exist.
The HP proofs require an input D that can actually do the opposite of whatever value that H returns. Such an input cannot possibly exist.H returns "D doesn't halt" and D halts. Seems possible.
A halt decider is certainly not required to report on the computationYes it is, if it contains that computation in turn.
that itself is contained within.
Thus HHH cannot report on the halt status of its caller because itDue to the "pathological relationship" its caller is the same as what
cannot see its caller.
On 5/14/2025 12:58 PM, Richard Heathfield wrote:
On 14/05/2025 18:46, olcott wrote:
PAY ATTENTION !!!
Oh, my dear dear chap - if I thought for a moment you had
anything worth paying attention to, I'd be all ears.
But you have nothing but mindless repetition, over and over and
OVER. For every article you post, I can pretty much guarantee
that I've read 90% of it before.
I repeat the steps that prove my point until
someone actually pays attention to these points
that prove I am correct.
All of the fake rebuttals of my work have no
other basis than the presumption the I must
be wrong.
On 5/14/2025 6:43 AM, Richard Damon wrote:
On 5/13/25 12:22 PM, olcott wrote:
On 5/13/2025 11:01 AM, olcott wrote:
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. >>>>>>>>> It seems there are only about 2 or 3 actual variations of what >>>>>>>>> PO is saying and all the rest is several thousand repeats by >>>>>>>>> both PO and responders...
Those who insist on responding to Olcott (of which I admit I
have occasionally been one despite my better intuitions) would >>>>>>>> be well advised to adopt something like the rule of ko (in the >>>>>>>> game go) which prohibits one from returning to the exact same
position. Simply repeating the same objection after olcott has >>>>>>>> ignored it is pointless. If he didn't get the objection the
fiftieth time he's not going to get it the fifty-first time either. >>>>>>>>
If people adopted this policy most of the threads on this forum >>>>>>>> would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his
dreams, he would see that his key points have been addresses and
refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
*DD emulated by HHH according to*
*the rules of the x86 language*
has never been explained. The closest thing to
reasoning that was provided on this point is
"that is what textbooks say".
ZFC reformulated set theory correcting its error
and the original set theory is now called naive
set theory.
When we understand that a termination analyzer
must compute the mapping from its input to the
behavior that this input actually specifies
then all of the conventional halting problem
proof fail.
But since that behavior is *DEFINED* to be the behavior of the program
represented when run, it is your PROOF that fails, because it uses a
strawman.
In other words ZFC is completely wrong because it did
not address the Russell's Paradox *that was defined in*
naive set theory.
On 5/14/2025 10:23 PM, Richard Damon wrote:
On 5/14/25 11:26 AM, olcott wrote:
On 5/14/2025 6:43 AM, Richard Damon wrote:
On 5/13/25 12:22 PM, olcott wrote:
On 5/13/2025 11:01 AM, olcott wrote:
On 5/13/2025 10:47 AM, Mike Terry wrote:
On 13/05/2025 12:54, Fred. Zwarts wrote:
Op 13.mei.2025 om 07:06 schreef olcott:
On 5/12/2025 11:41 PM, André G. Isaak wrote:
On 2025-05-12 21:23, Mike Terry wrote:
Mind you it does seem to have gone mad the last month or so. >>>>>>>>>>> It seems there are only about 2 or 3 actual variations of >>>>>>>>>>> what PO is saying and all the rest is several thousand
repeats by both PO and responders...
Those who insist on responding to Olcott (of which I admit I >>>>>>>>>> have occasionally been one despite my better intuitions) would >>>>>>>>>> be well advised to adopt something like the rule of ko (in the >>>>>>>>>> game go) which prohibits one from returning to the exact same >>>>>>>>>> position. Simply repeating the same objection after olcott has >>>>>>>>>> ignored it is pointless. If he didn't get the objection the >>>>>>>>>> fiftieth time he's not going to get it the fifty-first time >>>>>>>>>> either.
If people adopted this policy most of the threads on this
forum would be considerably shorter.
André
If people would actually address rather than
dishonestly dodge the key points that I making
they would see that I am correct.
If olcott would only stop ignoring everything that disturbs his >>>>>>>> dreams, he would see that his key points have been addresses and >>>>>>>> refuted many times already.
We might call that a disturbing ko.
Mike.
The actual reasoning why HHH is supposed to report
on the behavior of the direct execution of DD()
instead of the actual behavior that the finite
string of DD specifies:
*DD emulated by HHH according to*
*the rules of the x86 language*
has never been explained. The closest thing to
reasoning that was provided on this point is
"that is what textbooks say".
ZFC reformulated set theory correcting its error
and the original set theory is now called naive
set theory.
When we understand that a termination analyzer
must compute the mapping from its input to the
behavior that this input actually specifies
then all of the conventional halting problem
proof fail.
But since that behavior is *DEFINED* to be the behavior of the
program represented when run, it is your PROOF that fails, because
it uses a strawman.
In other words ZFC is completely wrong because it did
not address the Russell's Paradox *that was defined in*
naive set theory.
No, it dealt with Russell's Paradox by creating a brand new Set Theory
that wasn't suseptable to it.
ZFC didn't "fix" Naive Set Theory, as you can't do that, and still be
in it. They created an alternative, that did what people needed, so
they used it.
ZFC replaced the erroneous naive set theory.
You are welcome to try and create your POOPS that isn't susseptable to
the "problem" of non-computable Functions, but you need to actually
define you system, and it doesn't change the fact that in Classical
Comoputation Theory, there are non-computable functions (like Halting).
Of course, it is certain that your computation system will be a lot
less powerful, as that is what is needed to be done to get around the
"problem".
The spec sufficiently defines it.
<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/14/2025 4:14 PM, dbush wrote:
On 5/14/2025 2:59 PM, olcott wrote:
On 5/14/2025 1:45 PM, Richard Heathfield wrote:
On 14/05/2025 19:18, olcott wrote:
On 5/14/2025 12:58 PM, Richard Heathfield wrote:
On 14/05/2025 18:46, olcott wrote:
<snip>
PAY ATTENTION !!!
Oh, my dear dear chap - if I thought for a moment you had anything >>>>>> worth paying attention to, I'd be all ears.
But you have nothing but mindless repetition, over and over and
OVER. For every article you post, I can pretty much guarantee that >>>>>> I've read 90% of it before.
I repeat the steps that prove my point until
someone actually pays attention to these points
that prove I am correct.
And how is that strategy panning out for you?
The more you repeat, the less attention you get. All you get is
copy- paste rebuttals of your copy-paste claims.
THERE NEVER HAS BEEN ANY ACTUAL REBUTTAL OF ANY
OF MY ACTUAL CLAIMS. There has been rhetoric
that stupid people could mistake as rebuttal.
<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
And *yet again* you lie by implying Sipser agrees with your
interpretation of the above when definitive proof has been repeatedly
provided that he did not:
If that was actually true then you could provide an
alternative meaning for the exact words stated above.
I keep challenging you to provide this alternative
meaning and you dodge because you know that you are
lying about there being any alternative meaning
FOR THE EXACT WORDS LISTED ABOVE.
On 5/14/2025 12:15 PM, Richard Heathfield wrote:
On 14/05/2025 17:43, olcott wrote:
On 5/14/2025 11:16 AM, Richard Heathfield wrote:
On 14/05/2025 17:04, olcott wrote:The proof itself cannot exist because it is missing a key element.
The HP proofs require an input D that can actually do the oppositeAgreed. That is precisely what Turing proved.
of whatever value that H returns. Such an input cannot possibly
exist.
When you try to encode *AN INPUT* that actually does the opposite ofDD is exactly that.
whatever value that its termination analyzer returns in a fully
specified language such as C you will find this is impossible.
In a less fully specified language it is far too easy to get confusedDD (or its code) calling the aborting HHH is the input.
about what *AN INPUT* is and what it is not.
On 5/16/2025 8:25 AM, joes wrote:
Am Wed, 14 May 2025 12:22:26 -0500 schrieb olcott:
On 5/14/2025 12:15 PM, Richard Heathfield wrote:
On 14/05/2025 17:43, olcott wrote:
On 5/14/2025 11:16 AM, Richard Heathfield wrote:
On 14/05/2025 17:04, olcott wrote:The proof itself cannot exist because it is missing a key element.
The HP proofs require an input D that can actually do the opposite >>>>>>> of whatever value that H returns. Such an input cannot possiblyAgreed. That is precisely what Turing proved.
exist.
Yes, it is missing the halt decider.
When you try to encode *AN INPUT* that actually does the opposite ofDD is exactly that.
whatever value that its termination analyzer returns in a fully
specified language such as C you will find this is impossible.
In a less fully specified language it is far too easy to get confusedDD (or its code) calling the aborting HHH is the input.
about what *AN INPUT* is and what it is not.
int main()
{
DD(); // Only idiots expect HHH to report on its caller.
}
On 5/16/2025 9:09 AM, Richard Damon wrote:
On 5/16/25 10:00 AM, olcott wrote:
On 5/16/2025 8:25 AM, joes wrote:
Am Wed, 14 May 2025 12:22:26 -0500 schrieb olcott:
On 5/14/2025 12:15 PM, Richard Heathfield wrote:
On 14/05/2025 17:43, olcott wrote:
On 5/14/2025 11:16 AM, Richard Heathfield wrote:
On 14/05/2025 17:04, olcott wrote:The proof itself cannot exist because it is missing a key element.
The HP proofs require an input D that can actually do the opposite >>>>>>>>> of whatever value that H returns. Such an input cannot possibly >>>>>>>>> exist.Agreed. That is precisely what Turing proved.
Yes, it is missing the halt decider.
When you try to encode *AN INPUT* that actually does the opposite of >>>>> whatever value that its termination analyzer returns in a fullyDD is exactly that.
specified language such as C you will find this is impossible.
In a less fully specified language it is far too easy to get confused >>>>> about what *AN INPUT* is and what it is not.DD (or its code) calling the aborting HHH is the input.
int main()
{
DD(); // Only idiots expect HHH to report on its caller.
}
Only PATHOLOGICAL LIARS excpet that the call HHH(DD) doesn't mean to
answer about what the actual DD does when run,
Oh, I guess that answers who you are.
You just admitted that you think the truth is idiotic.
Mike explains all of the details of how the
Sipser quote does derive a correct Simulating Halt Decider.
On 5/14/2025 7:36 PM, Mike Terry wrote:
There is a natural (and correct) statement that Sipser
is far more likely (I'd say) to have agreed to.
First you should understand the basic idea behind a(Mike says much more about this)
"Simulating Halt Decider" (*SHD*) that /partially/
simulates its input, while observing each simulation
step looking for certain halting/non-halting patterns
in the simulation. A simple (working) example here
is an input which goes into a tight loop.
*Click here to get the whole article*
https://al.howardknight.net/? STYPE=msgid&MSGI=%3C1003cu5%242p3g1%241%40dont-email.me%3E
Message-ID: <1003cu5$2p3g1$1@dont-email.me>
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 499 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 53:57:10 |
| Calls: | 9,839 |
| Files: | 13,764 |
| Messages: | 6,194,481 |
| Posted today: | 1 |