*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine it represents when run,
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine it
represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine it
represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine it
represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You cannot possibly go through any reasoning to
show that I am incorrect. You only have a predefined
boiler-plate set of replies. So you just flunked
the Turing test.
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine it >>>>> represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
olcott kirjoitti 10.12.2025 klo 18.27:
DD() executed from main() calls HHH(DD) thus is
not one-and-the-same-thing as an argument to HHH.
If the last sentence is true then this is not the counter exmaple
mentioned in certain proofs of noncomputability of halting and
therefore not relevant in that context. The halting problem reuqires
that HHH can determine whether the counter example halts. That is,
you must be able to replace "???" in
#include <stdio.h> // or your replacement
int main (void)
{
int Halt_Status = HHH(???); // put the correct argument here
printf("HHH says: %s\n", Halt_Status ? "halts" : "does not halt");
return Halt_Status;
}
with whatever specifies the behaviour of DD to HHH. If you can't
do this then HHH is not a halt decider nor a partial halt decider.
olcott kirjoitti 10.12.2025 klo 15.04:
On 12/10/2025 3:43 AM, Mikko wrote:
polcott kirjoitti 10.12.2025 klo 0.27:
These are finally the long sought words that do
resolve the halting problem to a category error.
Turing machine deciders only compute the mapping from
their [finite string] inputs to an accept or reject
state on the basis that this [finite string] input
specifies or fails to specify a particular semantic
or syntactic property.
The above paragraph (acutally just one sentence) does not prove or
even say anything about the halting problem.
It is the definition of a decider that the halting
problem violates.
Nothing in the problem statement violates any definition. You can't
even quote the alleged "violation".
olcott kirjoitti 11.12.2025 klo 4.00:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
No, that is not a category error. If the question to be answered
is something other than "does this computation halt" then there
is not point to call the decider a "halting decider".
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
The usual defintion does the same. But usually the requirement is
that the solution to the problem includes encoding rules that
specify what the input shall be in order to specify the behaviour
asked about.
It is possible to pose the problem so that encoding rules are a
part of the problem specification. For example, the problem nay
present a particular unversal Turing machine and require that
the halting decider can be given the same input as that universal
Turing machine, which then is required to accept if that universal
Turing mahine halts with the same input and to reject otherwise.
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine
it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
On 12/11/2025 3:09 AM, Mikko wrote:
olcott kirjoitti 11.12.2025 klo 4.00:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
No, that is not a category error. If the question to be answered
is something other than "does this computation halt" then there
is not point to call the decider a "halting decider".
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
The usual defintion does the same. But usually the requirement is
that the solution to the problem includes encoding rules that
specify what the input shall be in order to specify the behaviour
asked about.
No this has always been the error of conflating the
behavior of the machine with the behavior specified
by the input finite string. In every case besides
pathological self-reference this makes no difference.
Turing machine deciders compute functions from finite
strings to {accept, reject}.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
It is possible to pose the problem so that encoding rules are a
part of the problem specification. For example, the problem nay
present a particular unversal Turing machine and require that
the halting decider can be given the same input as that universal
Turing machine, which then is required to accept if that universal
Turing mahine halts with the same input and to reject otherwise.
Even that is not the actual behavior actually specified
by its actual input even though most of the time it is
equivalent behavior.
The corrected halting problem requires a Turing machine
decider to report in the behavior that its finite string
input specifies.
This requires the halt decider be based on an augmented
UTM that watches the behavior of its simulated finite
string input.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
*Keeps repeating unless aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
On 12/11/25 8:47 AM, olcott wrote:
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine >>>>>>> it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
No, you argue for them based on unsupported claims.
TO PROVE something, you need to refer to the accepted AXIOM,
DEFINITIONS, and proven theorms in the system.
All you are doing is proving you don't know what you are talking about
and don't care how much reckless stupidity you show.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
No it doesn't. As your described code is not a "Program", AS IT IS
MISSING THE NEEDD CODE OF HHH.
On 12/11/2025 6:52 PM, Richard Damon wrote:
On 12/11/25 8:47 AM, olcott wrote:
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing Machine >>>>>>>> it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
No, you argue for them based on unsupported claims.
TO PROVE something, you need to refer to the accepted AXIOM,
DEFINITIONS, and proven theorms in the system.
All you are doing is proving you don't know what you are talking about
and don't care how much reckless stupidity you show.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
No it doesn't. As your described code is not a "Program", AS IT IS
MISSING THE NEEDD CODE OF HHH.
That HHH simulates DD according to the semantics of
C is fully enough specification. We could simply
imagine that HHH is a C emulator that can invoke
an instance of itself recursively.
*Very simple first principles showing the halting problem error*
*Very simple first principles showing the halting problem error*
*Very simple first principles showing the halting problem error*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error because Turing machines
only take finite string inputs.
The corrected halting problem requires a Turing
machine decider to report in the behavior that its
actual finite string input actually specifies.
*Very simple first principles showing the halting problem error*
On 12/11/25 8:06 PM, olcott wrote:If the above is the only thing in DD.c and
On 12/11/2025 6:52 PM, Richard Damon wrote:
On 12/11/25 8:47 AM, olcott wrote:
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing
Machine it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
No, you argue for them based on unsupported claims.
TO PROVE something, you need to refer to the accepted AXIOM,
DEFINITIONS, and proven theorms in the system.
All you are doing is proving you don't know what you are talking
about and don't care how much reckless stupidity you show.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
No it doesn't. As your described code is not a "Program", AS IT IS
MISSING THE NEEDD CODE OF HHH.
That HHH simulates DD according to the semantics of
C is fully enough specification. We could simply
imagine that HHH is a C emulator that can invoke
an instance of itself recursively.
But it CAN'T for the input given,
On 12/11/25 8:06 PM, olcott wrote:
*Very simple first principles showing the halting problem error*
And if you want to do this, then you need to start by stating the
principles you are using, and then the logical steps that get you to
what you are claiming.
On 12/11/2025 3:09 AM, Mikko wrote:
olcott kirjoitti 11.12.2025 klo 4.00:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
No, that is not a category error. If the question to be answered
is something other than "does this computation halt" then there
is not point to call the decider a "halting decider".
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
The usual defintion does the same. But usually the requirement is
that the solution to the problem includes encoding rules that
specify what the input shall be in order to specify the behaviour
asked about.
No this has always been the error of conflating the
behavior of the machine with the behavior specified
by the input finite string. In every case besides
pathological self-reference this makes no difference.
On 12/11/2025 7:21 PM, Richard Damon wrote:
On 12/11/25 8:06 PM, olcott wrote:
On 12/11/2025 6:52 PM, Richard Damon wrote:
On 12/11/25 8:47 AM, olcott wrote:
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing
Machine it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
No, you argue for them based on unsupported claims.
TO PROVE something, you need to refer to the accepted AXIOM,
DEFINITIONS, and proven theorms in the system.
All you are doing is proving you don't know what you are talking
about and don't care how much reckless stupidity you show.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
No it doesn't. As your described code is not a "Program", AS IT IS
MISSING THE NEEDD CODE OF HHH.
That HHH simulates DD according to the semantics of
C is fully enough specification. We could simply
imagine that HHH is a C emulator that can invoke
an instance of itself recursively.
But it CAN'T for the input given,
If the above is the only thing in DD.c and
HHH is an executable that
(a) Interprets DD.c
(b) Recognizes the call to itself and invokes
another instance of itself with the function
body of DD as char* input...
On 12/11/2025 3:00 AM, Mikko wrote:
olcott kirjoitti 10.12.2025 klo 15.04:
On 12/10/2025 3:43 AM, Mikko wrote:
polcott kirjoitti 10.12.2025 klo 0.27:
These are finally the long sought words that do
resolve the halting problem to a category error.
Turing machine deciders only compute the mapping from
their [finite string] inputs to an accept or reject
state on the basis that this [finite string] input
specifies or fails to specify a particular semantic
or syntactic property.
The above paragraph (acutally just one sentence) does not prove or
even say anything about the halting problem.
It is the definition of a decider that the halting
problem violates.
Nothing in the problem statement violates any definition. You can't
even quote the alleged "violation".
*It has taken me 21 years to derive these first principles*
olcott kirjoitti 11.12.2025 klo 18.05:
On 12/11/2025 3:09 AM, Mikko wrote:
olcott kirjoitti 11.12.2025 klo 4.00:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
No, that is not a category error. If the question to be answered
is something other than "does this computation halt" then there
is not point to call the decider a "halting decider".
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
The usual defintion does the same. But usually the requirement is
that the solution to the problem includes encoding rules that
specify what the input shall be in order to specify the behaviour
asked about.
No this has always been the error of conflating the
behavior of the machine with the behavior specified
by the input finite string. In every case besides
pathological self-reference this makes no difference.
As I said the usual formulation of the halting problem asks about
the behaviour of the machine. It is left to the solver of the
problem to crate encoding rules
to ensure that the behavour
specified by the input to the halting decider is the same as the
behaviour asked about.
If you don't like it that way you must post a pointer to the
formulation you think is better for your purposes.
olcott kirjoitti 12.12.2025 klo 3.44:
On 12/11/2025 7:21 PM, Richard Damon wrote:
On 12/11/25 8:06 PM, olcott wrote:
On 12/11/2025 6:52 PM, Richard Damon wrote:
On 12/11/25 8:47 AM, olcott wrote:
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing >>>>>>>>>>> Machine it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
No, you argue for them based on unsupported claims.
TO PROVE something, you need to refer to the accepted AXIOM,
DEFINITIONS, and proven theorms in the system.
All you are doing is proving you don't know what you are talking
about and don't care how much reckless stupidity you show.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
No it doesn't. As your described code is not a "Program", AS IT IS >>>>> MISSING THE NEEDD CODE OF HHH.
That HHH simulates DD according to the semantics of
C is fully enough specification. We could simply
imagine that HHH is a C emulator that can invoke
an instance of itself recursively.
But it CAN'T for the input given,
If the above is the only thing in DD.c and
HHH is an executable that
(a) Interprets DD.c
(b) Recognizes the call to itself and invokes
another instance of itself with the function
body of DD as char* input...
then the decider will report about a non-input, which is not what
the halting problem requires.
The halting problmem requires that
the input fully specifies the conputation asked about, which in
case of DD means that the input must also specify how the value of
HHH(DD) is computed.
The original halting problem is about Turing machines. An input to
a Turing machine must be complete because a Turing machine cannot
see anything else. If your input refers to something outside it
then it is not relevant to the halting problem.
On 12/11/2025 7:21 PM, Richard Damon wrote:
On 12/11/25 8:06 PM, olcott wrote:If the above is the only thing in DD.c and
On 12/11/2025 6:52 PM, Richard Damon wrote:
On 12/11/25 8:47 AM, olcott wrote:
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing
Machine it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
No, you argue for them based on unsupported claims.
TO PROVE something, you need to refer to the accepted AXIOM,
DEFINITIONS, and proven theorms in the system.
All you are doing is proving you don't know what you are talking
about and don't care how much reckless stupidity you show.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
No it doesn't. As your described code is not a "Program", AS IT IS
MISSING THE NEEDD CODE OF HHH.
That HHH simulates DD according to the semantics of
C is fully enough specification. We could simply
imagine that HHH is a C emulator that can invoke
an instance of itself recursively.
But it CAN'T for the input given,
HHH is an executable that
(a) Interprets DD.c
(b) Recognizes the call to itself and invokes
another instance of itself with the function
body of DD as char* input...
The execution trace of that alone proves that
the input to HHH(DD) does not halt.
On 12/11/2025 7:29 PM, Richard Damon wrote:
On 12/11/25 8:06 PM, olcott wrote:
*Very simple first principles showing the halting problem error*
And if you want to do this, then you need to start by stating the
principles you are using, and then the logical steps that get you to
what you are claiming.
Turing machine deciders compute functions from finite
strings to {accept, reject}.
The halting problem itself requires that deciders
compute the behavior of executing machines, thus
category error flat out and simple.
On 12/12/2025 2:27 AM, Mikko wrote:
olcott kirjoitti 12.12.2025 klo 3.44:
On 12/11/2025 7:21 PM, Richard Damon wrote:
On 12/11/25 8:06 PM, olcott wrote:
On 12/11/2025 6:52 PM, Richard Damon wrote:
On 12/11/25 8:47 AM, olcott wrote:
On 12/11/2025 6:14 AM, Richard Damon wrote:
On 12/10/25 10:33 PM, olcott wrote:
On 12/10/2025 9:21 PM, Richard Damon wrote:
On 12/10/25 9:19 PM, olcott wrote:
On 12/10/2025 8:13 PM, Richard Damon wrote:
On 12/10/25 9:00 PM, olcott wrote:
*It has take me 21 years to boil it down to this*
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
The corrected halting problem requires a Turing
machine decider to report in the behavior that
its finite string input specifies.
And since the input specifies the behavior of the Turing >>>>>>>>>>>> Machine it represents when run,
Counter-factual, but then you have only ever been
a somewhat smart bot stuck in rebuttal mode.
WHy do you say that?
What grounds do you have for that claim?
Do you even know what you are saying?
That is the behavior pattern that you have been
consistently showing with every post for years.
You mean asking you to actual prove your claims?
I always prove my claims you always dismiss them
with dogma and rhetoric utterly bereft of any of
any supporting reasoning like you just did.
No, you argue for them based on unsupported claims.
TO PROVE something, you need to refer to the accepted AXIOM,
DEFINITIONS, and proven theorms in the system.
All you are doing is proving you don't know what you are talking
about and don't care how much reckless stupidity you show.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
It is a verified fact that N steps of DD simulated
by HHH according to the semantics of the C programming
do prove a behavior pattern that cannot possibly reach
the "return" statement final halt state of DD in any
number of steps.
No it doesn't. As your described code is not a "Program", AS IT >>>>>> IS MISSING THE NEEDD CODE OF HHH.
That HHH simulates DD according to the semantics of
C is fully enough specification. We could simply
imagine that HHH is a C emulator that can invoke
an instance of itself recursively.
But it CAN'T for the input given,
If the above is the only thing in DD.c and
HHH is an executable that
(a) Interprets DD.c
(b) Recognizes the call to itself and invokes
another instance of itself with the function
body of DD as char* input...
then the decider will report about a non-input, which is not what
the halting problem requires.
How the hell is the file name DD.c not an input to HHH.exe?
The halting problmem requires that
the input fully specifies the conputation asked about, which in
case of DD means that the input must also specify how the value of
HHH(DD) is computed.
DD does specify that it calls HHH.
The original halting problem is about Turing machines. An input to
a Turing machine must be complete because a Turing machine cannot
see anything else. If your input refers to something outside it
then it is not relevant to the halting problem.
I do this in C to show all the relevant details
that are simply assumed away by the abstraction
of Turing machines.
*From the bottom of page 319 has been adapted to this* https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞, // accept state
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn // reject state
*Keeps repeating unless aborted*
(a) Ĥ copies its input ⟨Ĥ⟩
(b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩
(c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩
The exact same process occurs here except that
we cannot see the Turing machine source code
that proves the exact sequence of underlying steps.
In this case we can still see that ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly reach its own final halt
state of ⟨Ĥ.qn⟩. This is too difficult for most people
to understand so I do this in C.
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
HHH simulates DD that calls HHH(DD)
that simulates DD that calls HHH(DD)...
On 12/11/2025 2:53 AM, Mikko wrote:
olcott kirjoitti 10.12.2025 klo 18.27:
DD() executed from main() calls HHH(DD) thus is
not one-and-the-same-thing as an argument to HHH.
If the last sentence is true then this is not the counter exmaple
mentioned in certain proofs of noncomputability of halting and
therefore not relevant in that context. The halting problem reuqires
that HHH can determine whether the counter example halts. That is,
you must be able to replace "???" in
#include <stdio.h> // or your replacement
int main (void)
{
int Halt_Status = HHH(???); // put the correct argument here
printf("HHH says: %s\n", Halt_Status ? "halts" : "does not halt"); >> return Halt_Status;
}
with whatever specifies the behaviour of DD to HHH. If you can't
do this then HHH is not a halt decider nor a partial halt decider.
When the halting problem requires a halt decider
to report on the behavior of a Turing machine this
is always a category error.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,090 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 156:55:11 |
| Calls: | 13,922 |
| Calls today: | 3 |
| Files: | 187,021 |
| D/L today: |
4,131 files (1,056M bytes) |
| Messages: | 2,457,227 |