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 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 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.
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/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,089 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 153:54:31 |
| Calls: | 13,921 |
| Calls today: | 2 |
| Files: | 187,021 |
| D/L today: |
3,760 files (944M bytes) |
| Messages: | 2,457,163 |