olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said:typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said:
On 11/10/2025 3:43 AM, Mikko wrote:It is the behavour C semantics specifies. According to >>>>>>>>>>>>>>>>> C semantics
On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 11/9/2025 4:22 AM, Mikko wrote:
On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>
On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto to >>>>>>>>>>>>>>>>>>>>>>>>> the semantic and other
properties of D.
That's a stupid statement.
Stupid is better than false.
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) thatA question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
simulates D that calls H(D) that
simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>> simulation.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point*
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from H(D) >>>>>>>>>>>>>>>>>>> with the same
returned value as H(D) would return if executed, or >>>>>>>>>>>>>>>>>>> do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D) >>>>>>>>>>>>>>>>>> again and again.
If that happens then H does not return and therefore is >>>>>>>>>>>>>>>>> not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return"
statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" is >>>>>>>>>>>>> over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting
behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>> whether
a program terminates every time when used as it was designed >>>>>>>>>>> to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour asked >>>>>>>>> about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must include the >>>>>>> necessary access. Conversely, a proof that the necessary access is >>>>>>> impossible is sufficient to prove that halting problem is
unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the
requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify the
encoding rules so that the input contains the full specification of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it executes according to the x86 semantics. When DD is executed according to the x86 semantics it halts. Anybody who says that DD specifies a non-halting behaviour disagrees with the x86 semantics.
On 11/27/2025 1:49 AM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said:typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote:It is the behavour C semantics specifies. According to >>>>>>>>>>>>>>>>>> C semantics
On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/9/2025 4:22 AM, Mikko wrote:
On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto >>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other
properties of D.
That's a stupid statement.
Stupid is better than false.
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point*
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from H(D) >>>>>>>>>>>>>>>>>>>> with the same
returned value as H(D) would return if executed, or >>>>>>>>>>>>>>>>>>>> do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D) >>>>>>>>>>>>>>>>>>> again and again.
If that happens then H does not return and therefore >>>>>>>>>>>>>>>>>> is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return"
statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" is >>>>>>>>>>>>>> over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting
behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>>> whether
a program terminates every time when used as it was designed >>>>>>>>>>>> to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour >>>>>>>>>> asked about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must include the >>>>>>>> necessary access. Conversely, a proof that the necessary access is >>>>>>>> impossible is sufficient to prove that halting problem is
unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the
requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify the >>>> encoding rules so that the input contains the full specification of the >>>> behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it executes
according to the x86 semantics. When DD is executed according to the x86
semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
The DD that halts is not the same DD that is
an input to HHH(DD). The input to HHH(DD)
specifies non-halting behavior that HHH
recognizes and terminates.
Certainly you are no so ignorant that you
honestly believe that the caller of a function
is exactly one-and-the-same-thing as an
argument to this same function.
The DD that halts is not the same DD that is
an input to HHH(DD). The input to HHH(DD)
specifies non-halting behavior that HHH
recognizes and terminates.
On 11/27/25 10:21 AM, olcott wrote:
The DD that halts is not the same DD that is
an input to HHH(DD). The input to HHH(DD)
specifies non-halting behavior that HHH
recognizes and terminates.
Then somebody is lying.
As DD is supposed to call HHH with a representation of itself.
On 11/27/2025 1:49 AM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:The DD that halts is not the same DD that is
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said:typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote:It is the behavour C semantics specifies. According to >>>>>>>>>>>>>>>>>> C semantics
On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/9/2025 4:22 AM, Mikko wrote:
On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto >>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other
properties of D.
That's a stupid statement.
Stupid is better than false.
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point*
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from H(D) >>>>>>>>>>>>>>>>>>>> with the same
returned value as H(D) would return if executed, or >>>>>>>>>>>>>>>>>>>> do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>>> able to complete its first statement before calling H(D) >>>>>>>>>>>>>>>>>>> again and again.
If that happens then H does not return and therefore >>>>>>>>>>>>>>>>>> is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return"
statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" is >>>>>>>>>>>>>> over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting
behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>>> whether
a program terminates every time when used as it was designed >>>>>>>>>>>> to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour >>>>>>>>>> asked about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must include the >>>>>>>> necessary access. Conversely, a proof that the necessary access is >>>>>>>> impossible is sufficient to prove that halting problem is
unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the
requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify the >>>> encoding rules so that the input contains the full specification of the >>>> behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it executes
according to the x86 semantics. When DD is executed according to the x86
semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
an input to HHH(DD).
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said:typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote:It is the behavour C semantics specifies. According >>>>>>>>>>>>>>>>>>> to C semantics
On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>
On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto >>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
That's a stupid statement.
Stupid is better than false.
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, or >>>>>>>>>>>>>>>>>>>>> do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling >>>>>>>>>>>>>>>>>>>> H(D)
again and again.
If that happens then H does not return and therefore >>>>>>>>>>>>>>>>>>> is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return"
statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" is >>>>>>>>>>>>>>> over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting
behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>>>> whether
a program terminates every time when used as it was >>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour >>>>>>>>>>> asked about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must include >>>>>>>>> the
necessary access. Conversely, a proof that the necessary access is >>>>>>>>> impossible is sufficient to prove that halting problem is
unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the
requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify the >>>>> encoding rules so that the input contains the full specification of >>>>> the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it executes >>> according to the x86 semantics. When DD is executed according to the x86 >>> semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his
GitHub repository except when he wants to deceive with equivocation.
The DD is Olcotts repository halts.
olcott kirjoitti 27.11.2025 klo 17.21:
On 11/27/2025 1:49 AM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:The DD that halts is not the same DD that is
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said:typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote:It is the behavour C semantics specifies. According >>>>>>>>>>>>>>>>>>> to C semantics
On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>
On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto >>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
That's a stupid statement.
Stupid is better than false.
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, or >>>>>>>>>>>>>>>>>>>>> do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling >>>>>>>>>>>>>>>>>>>> H(D)
again and again.
If that happens then H does not return and therefore >>>>>>>>>>>>>>>>>>> is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return"
statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" is >>>>>>>>>>>>>>> over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting
behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>>>> whether
a program terminates every time when used as it was >>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour >>>>>>>>>>> asked about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must include >>>>>>>>> the
necessary access. Conversely, a proof that the necessary access is >>>>>>>>> impossible is sufficient to prove that halting problem is
unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the
requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify the >>>>> encoding rules so that the input contains the full specification of >>>>> the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it executes >>> according to the x86 semantics. When DD is executed according to the x86 >>> semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
an input to HHH(DD).
You didn't say "another DD" or anything else that would mean that "DD"
does not mean the same as usually, which is the DD stored in your GitHub repository. Therefore what you said is said about the same DD. That you
now claim you were deceiving with equivocation does not alter what you
said earlier.
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>It is the behavour C semantics specifies. According >>>>>>>>>>>>>>>>>>>> to C semantics
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto >>>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, >>>>>>>>>>>>>>>>>>>>>> or do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling >>>>>>>>>>>>>>>>>>>>> H(D)
again and again.
If that happens then H does not return and therefore >>>>>>>>>>>>>>>>>>>> is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>> statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" >>>>>>>>>>>>>>>> is over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting >>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>>>>> whether
a program terminates every time when used as it was >>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour >>>>>>>>>>>> asked about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must
include the
necessary access. Conversely, a proof that the necessary
access is
impossible is sufficient to prove that halting problem is >>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>> requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify >>>>>> the
encoding rules so that the input contains the full specification
of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it
executes
according to the x86 semantics. When DD is executed according to the
x86
semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his
GitHub repository except when he wants to deceive with equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
That DD simulated by HHH never stops running
unless aborted by HHH proves that the input
to HHH(DD) specifies non halting behavior.
Saying that that some other DD somewhere else
does stop as a rebuttal is only the strawman error.
A straw man fallacy (sometimes written as strawman)
is the informal fallacy of refuting an argument
different from the one actually under discussion,
while not recognizing or acknowledging the distinction. https://en.wikipedia.org/wiki/Straw_man
When the halting problem requires HHH to report
on the behavior of the DD executed from main()
this is erroneous:
(1) The caller of a function is never an argument to
this same function.
(2) The halting problem is requiring a halt decider
to report on behavior that is different that the behavior
specified by its input.
My work on the halting problem is only an aspect of
my project to make “true on the basis of meaning
expressed in language” reliably computable.
On 11/28/2025 2:18 AM, Mikko wrote:
olcott kirjoitti 27.11.2025 klo 17.21:
On 11/27/2025 1:49 AM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:The DD that halts is not the same DD that is
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>It is the behavour C semantics specifies. According >>>>>>>>>>>>>>>>>>>> to C semantics
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto >>>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, >>>>>>>>>>>>>>>>>>>>>> or do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling >>>>>>>>>>>>>>>>>>>>> H(D)
again and again.
If that happens then H does not return and therefore >>>>>>>>>>>>>>>>>>>> is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>> statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" >>>>>>>>>>>>>>>> is over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting >>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>>>>> whether
a program terminates every time when used as it was >>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour >>>>>>>>>>>> asked about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must
include the
necessary access. Conversely, a proof that the necessary
access is
impossible is sufficient to prove that halting problem is >>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>> requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify >>>>>> the
encoding rules so that the input contains the full specification
of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it
executes
according to the x86 semantics. When DD is executed according to the
x86
semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
an input to HHH(DD).
You didn't say "another DD" or anything else that would mean that "DD"
does not mean the same as usually, which is the DD stored in your GitHub
repository. Therefore what you said is said about the same DD. That you
now claim you were deceiving with equivocation does not alter what you
said earlier.
That DD simulated by HHH never stops running
unless aborted by HHH proves that the input
to HHH(DD) specifies non halting behavior.
The caller of a function is never an argument to
this same function. The DD executed in main that
calls HHH(DD) is not the same DD as the one that
HHH simulates.
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>It is the behavour C semantics specifies. According >>>>>>>>>>>>>>>>>>>> to C semantics
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all.On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and irrelevanto >>>>>>>>>>>>>>>>>>>>>>>>>>>> to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>
A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>> But yes, I did yesterday.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate H(D), >>>>>>>>>>>>>>>>>>>>>> either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, >>>>>>>>>>>>>>>>>>>>>> or do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never being >>>>>>>>>>>>>>>>>>>>> able to complete its first statement before calling >>>>>>>>>>>>>>>>>>>>> H(D)
again and again.
If that happens then H does not return and therefore >>>>>>>>>>>>>>>>>>>> is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>> statement final halt state for three years.
You yourself have not told the truth about
this even once.
That seems to confirm that the definition of "decider" >>>>>>>>>>>>>>>> is over your head.
I am just talking at the level of the execution
trace of C functions. D does specify non-halting >>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to determine >>>>>>>>>>>>>> whether
a program terminates every time when used as it was >>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller.
Every halt decider is required to report on the behaviour >>>>>>>>>>>> asked about.
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must
include the
necessary access. Conversely, a proof that the necessary
access is
impossible is sufficient to prove that halting problem is >>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>> requirements are wrong. It merely meas that HHH is not a halt
decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to specify >>>>>> the
encoding rules so that the input contains the full specification
of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it
executes
according to the x86 semantics. When DD is executed according to the
x86
semantics it halts. Anybody who says that DD specifies a non-halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his
GitHub repository except when he wants to deceive with equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
That DD simulated by HHH never stops running
unless aborted by HHH proves that the input
to HHH(DD) specifies non halting behavior.
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the behaviour >>>>>>>>>>>>> asked about.
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said:
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote:
On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>It is the behavour C semantics specifies. According >>>>>>>>>>>>>>>>>>>>> to C semantics
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>>>
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach its >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ownThat is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an incorrect >>>>>>>>>>>>>>>>>>>>>>> answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, >>>>>>>>>>>>>>>>>>>>>>> or do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D that >>>>>>>>>>>>>>>>>>>>>> calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result is >>>>>>>>>>>>>>>>>>>>> equally valid.
So D remains stuck in recursive simulation never >>>>>>>>>>>>>>>>>>>>>> being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about
DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of "decider" >>>>>>>>>>>>>>>>> is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider
correctly report on the behavior of its caller
and no halt decider can even see its actual caller. >>>>>>>>>>>>>
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>> include the
necessary access. Conversely, a proof that the necessary >>>>>>>>>>> access is
impossible is sufficient to prove that halting problem is >>>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>> decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to
specify the
encoding rules so that the input contains the full specification >>>>>>> of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86
language semantics. When an x86 processor executes a program it
executes
according to the x86 semantics. When DD is executed according to
the x86
semantics it halts. Anybody who says that DD specifies a non-halting >>>>> behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his
GitHub repository except when he wants to deceive with equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed
below. HHH always means the HHH on line 1081 except when otherwise
stated. HHH(DD) means the HHH on line 1081 is called with the pointer
to the DD on line 1355 as the argument. THat call returns 0, which
means that DD does not halt.
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the behaviour >>>>>>>>>>>>>> asked about.
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>> According to C semantics
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>>>>
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its ownThat is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, >>>>>>>>>>>>>>>>>>>>>>>> or do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D >>>>>>>>>>>>>>>>>>>>>>> that
calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result >>>>>>>>>>>>>>>>>>>>>> is equally valid.
So D remains stuck in recursive simulation never >>>>>>>>>>>>>>>>>>>>>>> being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of "decider" >>>>>>>>>>>>>>>>>> is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>> correctly report on the behavior of its caller
and no halt decider can even see its actual caller. >>>>>>>>>>>>>>
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>>> include the
necessary access. Conversely, a proof that the necessary >>>>>>>>>>>> access is
impossible is sufficient to prove that halting problem is >>>>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>>> decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to
specify the
encoding rules so that the input contains the full specification >>>>>>>> of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86 >>>>>> language semantics. When an x86 processor executes a program it
executes
according to the x86 semantics. When DD is executed according to
the x86
semantics it halts. Anybody who says that DD specifies a non-halting >>>>>> behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his
GitHub repository except when he wants to deceive with equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed
below. HHH always means the HHH on line 1081 except when otherwise
stated. HHH(DD) means the HHH on line 1081 is called with the pointer
to the DD on line 1355 as the argument. THat call returns 0, which
means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
The DD executed from main is the caller of HHH(DD) thus
cannot as be one-and-the-same-thing as an argument to HHH.
If you think so then you knowledge of C is abysmal.
The input to HHH(DD) specifies a non-halting sequence.
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the behaviour >>>>>>>>>>>>>> asked about.
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>> According to C semantics
On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in comp.theory. >>>>>>>>>>>>>>>>>>>>>>>>>>
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its ownThat is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell whether >>>>>>>>>>>>>>>>>>>>>>>> test.c halts is not
a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even
a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if executed, >>>>>>>>>>>>>>>>>>>>>>>> or do whatever H would
do if H would not not return.
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>>>> specifies.
simulator.exe simulates Test.c. This simulates D >>>>>>>>>>>>>>>>>>>>>>> that
calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result >>>>>>>>>>>>>>>>>>>>>> is equally valid.
So D remains stuck in recursive simulation never >>>>>>>>>>>>>>>>>>>>>>> being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of "decider" >>>>>>>>>>>>>>>>>> is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>> correctly report on the behavior of its caller
and no halt decider can even see its actual caller. >>>>>>>>>>>>>>
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>>> include the
necessary access. Conversely, a proof that the necessary >>>>>>>>>>>> access is
impossible is sufficient to prove that halting problem is >>>>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>>> decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to
specify the
encoding rules so that the input contains the full specification >>>>>>>> of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86 >>>>>> language semantics. When an x86 processor executes a program it
executes
according to the x86 semantics. When DD is executed according to
the x86
semantics it halts. Anybody who says that DD specifies a non-halting >>>>>> behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his
GitHub repository except when he wants to deceive with equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed
below. HHH always means the HHH on line 1081 except when otherwise
stated. HHH(DD) means the HHH on line 1081 is called with the pointer
to the DD on line 1355 as the argument. THat call returns 0, which
means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
olcott kirjoitti 29.11.2025 klo 18.38:
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the behaviour >>>>>>>>>>>>>>> asked about.
On 2025-11-13 15:50:37 +0000, olcott said:
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 11/12/2025 1:09 AM, Mikko wrote:
On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>typedef int (*ptr)();
On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>> According to C semantics
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>>>>> specifies.On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its ownThat is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D.
simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not
a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
instructions of H or simulating the return from >>>>>>>>>>>>>>>>>>>>>>>>> H(D) with the same
returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>
simulator.exe simulates Test.c. This simulates D >>>>>>>>>>>>>>>>>>>>>>>> that
calls H(D) that the simulator recognizes as itself. >>>>>>>>>>>>>>>>>>>>>>>
any other behavour that produces the same result >>>>>>>>>>>>>>>>>>>>>>> is equally valid.
So D remains stuck in recursive simulation never >>>>>>>>>>>>>>>>>>>>>>>> being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>> "decider" is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to its >>>>>>>>>>>>>>>>> termination
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>>>> include the
necessary access. Conversely, a proof that the necessary >>>>>>>>>>>>> access is
impossible is sufficient to prove that halting problem is >>>>>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>>>> decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to
specify the
encoding rules so that the input contains the full
specification of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86 >>>>>>> language semantics. When an x86 processor executes a program it >>>>>>> executes
according to the x86 semantics. When DD is executed according to >>>>>>> the x86
semantics it halts. Anybody who says that DD specifies a non-halting >>>>>>> behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his
GitHub repository except when he wants to deceive with equivocation. >>>>> The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed
below. HHH always means the HHH on line 1081 except when otherwise
stated. HHH(DD) means the HHH on line 1081 is called with the pointer
to the DD on line 1355 as the argument. THat call returns 0, which
means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
True. It would if HHH were a halting decider but HHH isn't.
[snip boring nonsense and lies]
On 12/1/2025 4:45 AM, Mikko wrote:
olcott kirjoitti 29.11.2025 klo 18.38:
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the >>>>>>>>>>>>>>>> behaviour asked about.
On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>
typedef int (*ptr)();On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
That is not the behavior that the input to H(D) >>>>>>>>>>>>>>>>>>>>>>>>> specifies.On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
It is stupidly false because you didn't bother >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>D simulated by H cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its ownThat is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never reaches >>>>>>>>>>>>>>>>>>>>>>>>>>>>> the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.A question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>> }
The above is in test.c
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt.
Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating
instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same
returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>
simulator.exe simulates Test.c. This simulates >>>>>>>>>>>>>>>>>>>>>>>>> D that
calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>> itself.
It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
any other behavour that produces the same result >>>>>>>>>>>>>>>>>>>>>>>> is equally valid.
So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>> never being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
Maybe my work is over your head.
Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>> "decider" is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to >>>>>>>>>>>>>>>>>> its termination
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>
And this is incorrect when it has not access to
the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>>>>> include the
necessary access. Conversely, a proof that the necessary >>>>>>>>>>>>>> access is
impossible is sufficient to prove that halting problem is >>>>>>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>>>>> decider.
That HHH fails to meet the requirements by itself does
not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to >>>>>>>>>> specify the
encoding rules so that the input contains the full
specification of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the x86 >>>>>>>> language semantics. When an x86 processor executes a program it >>>>>>>> executes
according to the x86 semantics. When DD is executed according to >>>>>>>> the x86
semantics it halts. Anybody who says that DD specifies a non- >>>>>>>> halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his >>>>>> GitHub repository except when he wants to deceive with equivocation. >>>>>> The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed
below. HHH always means the HHH on line 1081 except when otherwise
stated. HHH(DD) means the HHH on line 1081 is called with the pointer
to the DD on line 1355 as the argument. THat call returns 0, which
means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
True. It would if HHH were a halting decider but HHH isn't.
If you carefully studied all of what I said you
would see that the halting problem is a category
error because it directly contradicts one of the
foundational axioms of computer science.
olcott kirjoitti 1.12.2025 klo 14.47:
On 12/1/2025 4:45 AM, Mikko wrote:
olcott kirjoitti 29.11.2025 klo 18.38:
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said:
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the >>>>>>>>>>>>>>>>> behaviour asked about.
On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 11/13/2025 2:48 AM, Mikko wrote:
On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>
typedef int (*ptr)();On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>Maybe the definition of "decider" is over your head. >>>>>>>>>>>>>>>>>>>>>>
On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>
That is not the behavior that the input to >>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider.
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
It is stupidly false because you didn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> botherOn 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>D simulated by H cannot possibly reach >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> its ownThat is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reachesA question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>>> }
The above is in test.c >>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt. >>>>>>>>>>>>>>>>>>>>>>>>>>>
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating >>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same
returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>>
simulator.exe simulates Test.c. This simulates >>>>>>>>>>>>>>>>>>>>>>>>>> D that
calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>>> itself.
It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
any other behavour that produces the same >>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.
So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>>> never being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider.
Maybe my work is over your head. >>>>>>>>>>>>>>>>>>>>>>>
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer.
The termination problem is not about specifying "to >>>>>>>>>>>>>>>>>>> its termination
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>>
And this is incorrect when it has not access to >>>>>>>>>>>>>>>> the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>>>>>> include the
necessary access. Conversely, a proof that the necessary >>>>>>>>>>>>>>> access is
impossible is sufficient to prove that halting problem is >>>>>>>>>>>>>>> unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that the >>>>>>>>>>>>> requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>>>>>> decider.
That HHH fails to meet the requirements by itself does >>>>>>>>>>>> not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic
property.
That the information that HHH is required to report
on simply is not contained in its input is what makes
the requirements wrong.
No, it merely means that the designer ot HHH has failed to >>>>>>>>>>> specify the
encoding rules so that the input contains the full
specification of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about the >>>>>>>>> x86
language semantics. When an x86 processor executes a program it >>>>>>>>> executes
according to the x86 semantics. When DD is executed according >>>>>>>>> to the x86
semantics it halts. Anybody who says that DD specifies a non- >>>>>>>>> halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his >>>>>>> GitHub repository except when he wants to deceive with equivocation. >>>>>>> The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed
below. HHH always means the HHH on line 1081 except when otherwise
stated. HHH(DD) means the HHH on line 1081 is called with the pointer >>>>> to the DD on line 1355 as the argument. THat call returns 0, which
means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
True. It would if HHH were a halting decider but HHH isn't.
If you carefully studied all of what I said you
would see that the halting problem is a category
error because it directly contradicts one of the
foundational axioms of computer science.
Any statement that a problem contradicts anything is a categoryerror.
On 12/2/2025 3:07 AM, Mikko wrote:
olcott kirjoitti 1.12.2025 klo 14.47:
On 12/1/2025 4:45 AM, Mikko wrote:
olcott kirjoitti 29.11.2025 klo 18.38:
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the >>>>>>>>>>>>>>>>>> behaviour asked about.
On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/13/2025 2:48 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>The termination problem is not about specifying "to >>>>>>>>>>>>>>>>>>>> its termination
On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>
On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>Maybe the definition of "decider" is over your >>>>>>>>>>>>>>>>>>>>>>>> head.
Maybe my work is over your head. >>>>>>>>>>>>>>>>>>>>>>>>On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>
That is not the behavior that the input to >>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
It is stupidly false because you didn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> botherOn 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reachesA question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in recursive >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulation.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
The above is in test.c >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should simulate >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D), either simultating >>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same >>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>>>
simulator.exe simulates Test.c. This >>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>>>> itself.
It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics
any other behavour that produces the same >>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid.
So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>>>> never being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider. >>>>>>>>>>>>>>>>>>>>>>>>>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer. >>>>>>>>>>>>>>>>>>>>
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>>>
And this is incorrect when it has not access to >>>>>>>>>>>>>>>>> the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>>>>>>> include the
necessary access. Conversely, a proof that the necessary >>>>>>>>>>>>>>>> access is
impossible is sufficient to prove that halting problem >>>>>>>>>>>>>>>> is unsolvable.
Reporing on the behavior of DD() executed from
main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean that >>>>>>>>>>>>>> the
requirements are wrong. It merely meas that HHH is not a halt >>>>>>>>>>>>>> decider.
That HHH fails to meet the requirements by itself does >>>>>>>>>>>>> not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic >>>>>>>>>>>>> property.
That the information that HHH is required to report
on simply is not contained in its input is what makes >>>>>>>>>>>>> the requirements wrong.
No, it merely means that the designer ot HHH has failed to >>>>>>>>>>>> specify the
encoding rules so that the input contains the full
specification of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about >>>>>>>>>> the x86
language semantics. When an x86 processor executes a program >>>>>>>>>> it executes
according to the x86 semantics. When DD is executed according >>>>>>>>>> to the x86
semantics it halts. Anybody who says that DD specifies a non- >>>>>>>>>> halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in his >>>>>>>> GitHub repository except when he wants to deceive with
equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed >>>>>> below. HHH always means the HHH on line 1081 except when otherwise >>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the pointer >>>>>> to the DD on line 1355 as the argument. THat call returns 0, which >>>>>> means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
True. It would if HHH were a halting decider but HHH isn't.
If you carefully studied all of what I said you
would see that the halting problem is a category
error because it directly contradicts one of the
foundational axioms of computer science.
Any statement that a problem contradicts anything is a categoryerror.
Flibble was the first one to use this term that I am aware of.
olcott kirjoitti 2.12.2025 klo 16.14:
On 12/2/2025 3:07 AM, Mikko wrote:
olcott kirjoitti 1.12.2025 klo 14.47:
On 12/1/2025 4:45 AM, Mikko wrote:
olcott kirjoitti 29.11.2025 klo 18.38:
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said:
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>>
On 11/14/2025 3:21 AM, Mikko wrote:Every halt decider is required to report on the >>>>>>>>>>>>>>>>>>> behaviour asked about.
On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>
On 11/13/2025 2:48 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>The termination problem is not about specifying "to >>>>>>>>>>>>>>>>>>>>> its termination
On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>
On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>Maybe the definition of "decider" is over your >>>>>>>>>>>>>>>>>>>>>>>>> head.
Maybe my work is over your head. >>>>>>>>>>>>>>>>>>>>>>>>>On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That is not the behavior that the input to >>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
It is stupidly false because you didn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> botherOn 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reachesA question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
the simulated "return" statement final halt >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> state of D because D calls H(D) in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive
simulation.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
The above is in test.c >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source file >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from the command prompt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate H(D), either simultating >>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same >>>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulator.exe simulates Test.c. This >>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.
It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics >>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same >>>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid. >>>>>>>>>>>>>>>>>>>>>>>>>>>
So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>>>>> never being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider. >>>>>>>>>>>>>>>>>>>>>>>>>>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer. >>>>>>>>>>>>>>>>>>>>>
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it was >>>>>>>>>>>>>>>>>>>>> designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>>>>
And this is incorrect when it has not access to >>>>>>>>>>>>>>>>>> the behavior that it is asked about.
No, it is not. The solution to the halting problem must >>>>>>>>>>>>>>>>> include the
necessary access. Conversely, a proof that the >>>>>>>>>>>>>>>>> necessary access is
impossible is sufficient to prove that halting problem >>>>>>>>>>>>>>>>> is unsolvable.
Reporing on the behavior of DD() executed from >>>>>>>>>>>>>>>> main requires HHH to report on information
that is not contained in its input thus it is
incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean >>>>>>>>>>>>>>> that the
requirements are wrong. It merely meas that HHH is not a >>>>>>>>>>>>>>> halt
decider.
That HHH fails to meet the requirements by itself does >>>>>>>>>>>>>> not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic >>>>>>>>>>>>>> property.
That the information that HHH is required to report >>>>>>>>>>>>>> on simply is not contained in its input is what makes >>>>>>>>>>>>>> the requirements wrong.
No, it merely means that the designer ot HHH has failed to >>>>>>>>>>>>> specify the
encoding rules so that the input contains the full
specification of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about >>>>>>>>>>> the x86
language semantics. When an x86 processor executes a program >>>>>>>>>>> it executes
according to the x86 semantics. When DD is executed according >>>>>>>>>>> to the x86
semantics it halts. Anybody who says that DD specifies a non- >>>>>>>>>>> halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program in >>>>>>>>> his
GitHub repository except when he wants to deceive with
equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed >>>>>>> below. HHH always means the HHH on line 1081 except when otherwise >>>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the
pointer
to the DD on line 1355 as the argument. THat call returns 0, which >>>>>>> means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
True. It would if HHH were a halting decider but HHH isn't.
If you carefully studied all of what I said you
would see that the halting problem is a category
error because it directly contradicts one of the
foundational axioms of computer science.
Any statement that a problem contradicts anything is a categoryerror.
Flibble was the first one to use this term that I am aware of.
Do you mean the term "category error"? It is a well known term
though many authors prefer "category mistake" for the same
meaning.
Anyway, any claim that a problem contradict something is
a category error because the meanings of "problem" and
"contradict" are not compatible.
On 12/3/2025 5:34 AM, Mikko wrote:
olcott kirjoitti 2.12.2025 klo 16.14:
On 12/2/2025 3:07 AM, Mikko wrote:
olcott kirjoitti 1.12.2025 klo 14.47:
On 12/1/2025 4:45 AM, Mikko wrote:
olcott kirjoitti 29.11.2025 klo 18.38:
On 11/29/2025 3:27 AM, Mikko wrote:
olcott kirjoitti 28.11.2025 klo 16.46:
On 11/28/2025 2:14 AM, Mikko wrote:
Chris M. Thomasson kirjoitti 27.11.2025 klo 9.58:
On 11/26/2025 11:49 PM, Mikko wrote:
olcott kirjoitti 26.11.2025 klo 17.17:
On 11/26/2025 4:01 AM, Mikko wrote:
olcott kirjoitti 17.11.2025 klo 15.31:
On 11/17/2025 2:43 AM, Mikko wrote:
On 2025-11-17 00:12:14 +0000, olcott said:
On 11/16/2025 3:18 AM, Mikko wrote:
On 2025-11-15 16:12:49 +0000, olcott said: >>>>>>>>>>>>>>>>>>
On 11/15/2025 4:15 AM, Mikko wrote:
On 2025-11-14 15:00:09 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>
On 11/14/2025 3:21 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>> On 2025-11-13 15:50:37 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>Every halt decider is required to report on the >>>>>>>>>>>>>>>>>>>> behaviour asked about.
On 11/13/2025 2:48 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-12 12:54:12 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>The termination problem is not about specifying >>>>>>>>>>>>>>>>>>>>>> "to its termination
On 11/12/2025 1:09 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-11 13:04:13 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>
On 11/11/2025 2:59 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-10 14:48:00 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>Maybe the definition of "decider" is over your >>>>>>>>>>>>>>>>>>>>>>>>>> head.
Maybe my work is over your head. >>>>>>>>>>>>>>>>>>>>>>>>>>On 11/10/2025 3:43 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-09 12:51:57 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That is not the behavior that the input to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> H(D) specifies.On 11/9/2025 4:22 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-08 13:36:06 +0000, olcott said: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Any program that does not correctly tell >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> whether test.c halts is not >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a halt decider. A program that gives an >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incorrect answer is not even >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a partial halt decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
*This is my key foundational point* >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>On 11/8/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-07 12:57:48 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:A statement about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory.
It is stupidly false because you didn't >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bother
On 11/7/2025 2:05 AM, Mikko wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 2025-11-06 20:48:02 +0000, olcott >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> said:Stupid is better than false. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
That's a stupid statement. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
D simulated by H cannot possibly >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reach its own >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulated final halt state. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>That is merely a defect in H and >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> irrelevanto to the semantic and other >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> properties of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
to pay any attention at all. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
H simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that calls H(D) that never >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reachesA question about me is off topic in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> comp.theory. But yes, I did yesterday. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
the simulated "return" statement final >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> halt
state of D because D calls H(D) in >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> recursive
simulation.
Have you ever done any actual programming? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
int H(char* P);
int D()
{
int Halt_Status = H(D); >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> HERE: goto HERE; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> return Halt_Status; >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> }
The above is in test.c >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate.exe implements a C interpreter. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulate test.c
runs the interpreter on the above source >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> file
from the command prompt. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
When this interpreter sees the call to H(D) >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> it calls itself with the text body of D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>According to C semanttics it should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulate H(D), either simultating >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> instructions of H or simulating the return >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from H(D) with the same >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> returned value as H(D) would return if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> executed, or do whatever H would >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> do if H would not not return. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
simulator.exe simulates Test.c. This >>>>>>>>>>>>>>>>>>>>>>>>>>>>> simulates D that
calls H(D) that the simulator recognizes as >>>>>>>>>>>>>>>>>>>>>>>>>>>>> itself.
It is the behavour C semantics specifies. >>>>>>>>>>>>>>>>>>>>>>>>>>>> According to C semantics >>>>>>>>>>>>>>>>>>>>>>>>>>>> any other behavour that produces the same >>>>>>>>>>>>>>>>>>>>>>>>>>>> result is equally valid. >>>>>>>>>>>>>>>>>>>>>>>>>>>>
So D remains stuck in recursive simulation >>>>>>>>>>>>>>>>>>>>>>>>>>>>> never being
able to complete its first statement before >>>>>>>>>>>>>>>>>>>>>>>>>>>>> calling H(D)
again and again.
If that happens then H does not return and >>>>>>>>>>>>>>>>>>>>>>>>>>>> therefore is not a decider. >>>>>>>>>>>>>>>>>>>>>>>>>>>
typedef int (*ptr)();
int HHH(ptr P);
int DD()
{
int Halt_Status = HHH(DD); >>>>>>>>>>>>>>>>>>>>>>>>> if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
int main()
{
HHH(DD);
}
People here have consistently lied about >>>>>>>>>>>>>>>>>>>>>>>>> DD simulated by HHH reaching its own "return" >>>>>>>>>>>>>>>>>>>>>>>>> statement final halt state for three years. >>>>>>>>>>>>>>>>>>>>>>>>>
You yourself have not told the truth about >>>>>>>>>>>>>>>>>>>>>>>>> this even once.
That seems to confirm that the definition of >>>>>>>>>>>>>>>>>>>>>>>> "decider" is over your head.
I am just talking at the level of the execution >>>>>>>>>>>>>>>>>>>>>>> trace of C functions. D does specify non-halting >>>>>>>>>>>>>>>>>>>>>>> behavior to its termination analyzer. >>>>>>>>>>>>>>>>>>>>>>
analyzer". Instead the termination problem is to >>>>>>>>>>>>>>>>>>>>>> determine whether
a program terminates every time when used as it >>>>>>>>>>>>>>>>>>>>>> was designed to be
used.
The halting problem requires that a halt decider >>>>>>>>>>>>>>>>>>>>> correctly report on the behavior of its caller >>>>>>>>>>>>>>>>>>>>> and no halt decider can even see its actual caller. >>>>>>>>>>>>>>>>>>>>
And this is incorrect when it has not access to >>>>>>>>>>>>>>>>>>> the behavior that it is asked about.
No, it is not. The solution to the halting problem >>>>>>>>>>>>>>>>>> must include the
necessary access. Conversely, a proof that the >>>>>>>>>>>>>>>>>> necessary access is
impossible is sufficient to prove that halting problem >>>>>>>>>>>>>>>>>> is unsolvable.
Reporing on the behavior of DD() executed from >>>>>>>>>>>>>>>>> main requires HHH to report on information
that is not contained in its input thus it is >>>>>>>>>>>>>>>>> incorrect to require HHH to report on that.
That HHH fails to meet the requirements does not mean >>>>>>>>>>>>>>>> that the
requirements are wrong. It merely meas that HHH is not a >>>>>>>>>>>>>>>> halt
decider.
That HHH fails to meet the requirements by itself does >>>>>>>>>>>>>>> not mean that the requirements are wrong.
Turing machine deciders only compute a 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 semantic or syntactic >>>>>>>>>>>>>>> property.
That the information that HHH is required to report >>>>>>>>>>>>>>> on simply is not contained in its input is what makes >>>>>>>>>>>>>>> the requirements wrong.
No, it merely means that the designer ot HHH has failed to >>>>>>>>>>>>>> specify the
encoding rules so that the input contains the full >>>>>>>>>>>>>> specification of the
behaviour.
In other words you are trying to get away with
disagreeing with the semantics of the x86 language
or the semantics of the C programing language.
You are the one who disagrees with the x86 processors about >>>>>>>>>>>> the x86
language semantics. When an x86 processor executes a program >>>>>>>>>>>> it executes
according to the x86 semantics. When DD is executed
according to the x86
semantics it halts. Anybody who says that DD specifies a >>>>>>>>>>>> non- halting
behaviour disagrees with the x86 semantics.
But, DD can halt or not halt, right?
When Olcott uses the name DD he means the particular program >>>>>>>>>> in his
GitHub repository except when he wants to deceive with
equivocation.
The DD is Olcotts repository halts.
I am doing this in the C programming language so that
every detail can be concretely specified and thus no
important details are simply abstracted away.
https://github.com/plolcott/x86utm/blob/master/Halt7.c
HHH on line 1081
DD on line 1355
The DD on line 1355 is the DD I mentioned above and whicn is listed >>>>>>>> below. HHH always means the HHH on line 1081 except when otherwise >>>>>>>> stated. HHH(DD) means the HHH on line 1081 is called with the >>>>>>>> pointer
to the DD on line 1355 as the argument. THat call returns 0, which >>>>>>>> means that DD does not halt.
HHH(DD)==0 has nothing to do with DD executed from main.
True. It would if HHH were a halting decider but HHH isn't.
If you carefully studied all of what I said you
would see that the halting problem is a category
error because it directly contradicts one of the
foundational axioms of computer science.
Any statement that a problem contradicts anything is a categoryerror.
Flibble was the first one to use this term that I am aware of.
Anyway, any claim that a problem contradict something is
a category error because the meanings of "problem" and
"contradict" are not compatible.
When the halting problem contradicts the definition
of a Turing machine decider
olcott kirjoitti 3.12.2025 klo 18.27:
On 12/3/2025 5:34 AM, Mikko wrote:
olcott kirjoitti 2.12.2025 klo 16.14:
Flibble was the first one to use this term that I am aware of.
It does not matter who first used the term here.
...
Anyway, any claim that a problem contradict something is
a category error because the meanings of "problem" and
"contradict" are not compatible.
When the halting problem contradicts the definition
of a Turing machine decider
A contradiction means that all claims of some set cannot be true. It
is a category error to apply the term "contradiction" to non-claims.
Examples of non-claims are problem and definition. An example of
category error is "the halting problem contradicts the definition of
a Turing machine decider".
On 12/4/2025 3:17 AM, Mikko wrote:
olcott kirjoitti 3.12.2025 klo 18.27:
On 12/3/2025 5:34 AM, Mikko wrote:
olcott kirjoitti 2.12.2025 klo 16.14:
Flibble was the first one to use this term that I am aware of.
It does not matter who first used the term here.
...
Anyway, any claim that a problem contradict something is
a category error because the meanings of "problem" and
"contradict" are not compatible.
When the halting problem contradicts the definition
of a Turing machine decider
A contradiction means that all claims of some set cannot be true. It
is a category error to apply the term "contradiction" to non-claims.
Examples of non-claims are problem and definition. An example of
category error is "the halting problem contradicts the definition of
a Turing machine decider".
The halting problem contradicts the definition
of a Turing machine decider proving that it is
wrong because the definition of a Turing machine
decider is foundational.
olcott kirjoitti 4.12.2025 klo 16.15:
On 12/4/2025 3:17 AM, Mikko wrote:
olcott kirjoitti 3.12.2025 klo 18.27:
On 12/3/2025 5:34 AM, Mikko wrote:
olcott kirjoitti 2.12.2025 klo 16.14:
Flibble was the first one to use this term that I am aware of.
It does not matter who first used the term here.
...
Anyway, any claim that a problem contradict something is
a category error because the meanings of "problem" and
"contradict" are not compatible.
When the halting problem contradicts the definition
of a Turing machine decider
A contradiction means that all claims of some set cannot be true. It
is a category error to apply the term "contradiction" to non-claims.
Examples of non-claims are problem and definition. An example of
category error is "the halting problem contradicts the definition of
a Turing machine decider".
The halting problem contradicts the definition
of a Turing machine decider proving that it is
wrong because the definition of a Turing machine
decider is foundational.
That still contains the same category error pointed out in my
prevous comment as quoted above.
olcott kirjoitti 4.12.2025 klo 16.15:
On 12/4/2025 3:17 AM, Mikko wrote:
olcott kirjoitti 3.12.2025 klo 18.27:
On 12/3/2025 5:34 AM, Mikko wrote:
olcott kirjoitti 2.12.2025 klo 16.14:
Flibble was the first one to use this term that I am aware of.
It does not matter who first used the term here.
...
Anyway, any claim that a problem contradict something is
a category error because the meanings of "problem" and
"contradict" are not compatible.
When the halting problem contradicts the definition
of a Turing machine decider
A contradiction means that all claims of some set cannot be true. It
is a category error to apply the term "contradiction" to non-claims.
Examples of non-claims are problem and definition. An example of
category error is "the halting problem contradicts the definition of
a Turing machine decider".
The halting problem contradicts the definition
of a Turing machine decider proving that it is
wrong because the definition of a Turing machine
decider is foundational.
That still contains the same category error pointed out in my
prevous comment as quoted above.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,089 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 153:45:29 |
| Calls: | 13,921 |
| Calls today: | 2 |
| Files: | 187,021 |
| D/L today: |
3,744 files (941M bytes) |
| Messages: | 2,457,162 |