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:
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:
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.
Have you ever done any actual programming?
A question about me is off topic in comp.theory. But yes, I >>>>>>>>>>> did yesterday.
*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.
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.
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.
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.
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:And this is incorrect when it has not access to
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:
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.
Have you ever done any actual programming?
A question about me is off topic in comp.theory. But >>>>>>>>>>>>>>>>> yes, I did yesterday.
*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.
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.
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. >>>>
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.
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:
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) 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
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.
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.
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.
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:Reporing on the behavior of DD() executed from
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:
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) 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
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.
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.
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. >>>>
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.
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:Reporing on the behavior of DD() executed from
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) 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
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. >>>>>
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.
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.
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown
with code.
On 2025-11-05, olcott <polcott333@gmail.com> wrote:
The whole point is that D simulated by H
cannot possbly reach its own simulated
"return" statement no matter what H does.
Yes; this doesn't happen while H is running.
So while H does /something/, no matter what H does,
that D simulation won't reach the return statement.
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state conclusively proves otherwise.
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state
conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown >>>>> with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state
conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown >>>>>> with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state
conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results >>>>>>> shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown >>>>>>> with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
This simulation is "resumed" at the "return"
instruction.
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown >>>>>>>> with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
No, you fucking idiot.
This simulation is "resumed" at the "return"
instruction.
No, you fucking idiot.
"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."
See above.
On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown >>>>>>>>> with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
No, you fucking idiot.
This simulation is "resumed" at the "return"
instruction.
No, you fucking idiot.
"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."
See above.
I discussed you (not by name) with Claude AI.
It is convinced that you must be a liar.
I will fix this by actually adapting a C interpreter
to prove that you are a liar to anyone that knows C.
I tried to do this with x86 yet this proved far
too difficult for even the chief editor of one
of the most prestigious computer science journals.
When you resume any simulation that cannot possibly
stop running to the exact same total machine state
Ben Bacarisse would confirm that this one also
would never stop running.
On 2025-11-27, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
No, you fucking idiot.
This simulation is "resumed" at the "return"
instruction.
No, you fucking idiot.
"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."
See above.
I discussed you (not by name) with Claude AI.
It is convinced that you must be a liar.
Right; anything but atually get to grips with some code.
I will fix this by actually adapting a C interpreter
to prove that you are a liar to anyone that knows C.
I tried to do this with x86 yet this proved far
too difficult for even the chief editor of one
of the most prestigious computer science journals.
It is child's play to show that your claims based on
that x86 contraption are incorrect.
When you resume any simulation that cannot possibly
stop running to the exact same total machine state
No, only the state of the simulation is resumed, not
the total machine state.
On 11/26/2025 6:39 PM, Kaz Kylheku wrote:
On 2025-11-27, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to >>>>>>>>>>> results shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting >>>>>>>>> state
conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
No, you fucking idiot.
This simulation is "resumed" at the "return"
instruction.
No, you fucking idiot.
"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."
See above.
I discussed you (not by name) with Claude AI.
It is convinced that you must be a liar.
Right; anything but atually get to grips with some code.
I will fix this by actually adapting a C interpreter
to prove that you are a liar to anyone that knows C.
I tried to do this with x86 yet this proved far
too difficult for even the chief editor of one
of the most prestigious computer science journals.
It is child's play to show that your claims based on
that x86 contraption are incorrect.
When you resume any simulation that cannot possibly
stop running to the exact same total machine state
No, only the state of the simulation is resumed, not
the total machine state.
Great you finally admit that you are cheating.
On 11/26/2025 6:39 PM, Kaz Kylheku wrote:
On 2025-11-27, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>>>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
No, you fucking idiot.
This simulation is "resumed" at the "return"
instruction.
No, you fucking idiot.
"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."
See above.
I discussed you (not by name) with Claude AI.
It is convinced that you must be a liar.
Right; anything but atually get to grips with some code.
I will fix this by actually adapting a C interpreter
to prove that you are a liar to anyone that knows C.
I tried to do this with x86 yet this proved far
too difficult for even the chief editor of one
of the most prestigious computer science journals.
It is child's play to show that your claims based on
that x86 contraption are incorrect.
When you resume any simulation that cannot possibly
stop running to the exact same total machine state
No, only the state of the simulation is resumed, not
the total machine state.
Great you finally admit that you are cheating.
Anyone knowing comp.theory will understand this
is cheating.
On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown >>>>>>>>> with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
No, you fucking idiot.
This simulation is "resumed" at the "return"
instruction.
No, you fucking idiot.
"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."
See above.
I discussed you (not by name) with Claude AI.
It is convinced that you must be a liar.
I will fix this by actually adapting a C interpreter
to prove that you are a liar to anyone that knows C.
I tried to do this with x86 yet this proved far
too difficult for even the chief editor of one
of the most prestigious computer science journals.
When you resume any simulation that cannot possibly
stop running to the exact same total machine state
Ben Bacarisse would confirm that this one also
would never stop running.
On 2025-11-27, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 5:55 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 4:19 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
On 11/26/2025 3:47 PM, Kaz Kylheku wrote:
On 2025-11-26, dbush <dbush.mobile@gmail.com> wrote:
On 11/26/2025 2:55 PM, olcott wrote:
On 11/26/2025 12:35 PM, Kaz Kylheku wrote:
On 2025-11-26, olcott <polcott333@gmail.com> wrote:
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.
Says the pitiful twit who has no meaningful response to results shown
with code.
I am not the one that came up with the jackass idea
of restarting a simulation after it has already
conclusively proved that it cannot possibly halt.
That the continuation of the simulation reaches a final halting state >>>>>>>> conclusively proves otherwise.
And Olcott has no idea how to fix it and is no longer
able to engage with tasks involving code.
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
And the continuation of the simulation
at the "return" statement "proves"
by deception that infinite loops halt.
I have no idea what you are blabbing about, and neither do you.
We could simulate Infinite_Loop() until it
proves that it cannot possibly stop running
unless aborted, then abort it. Now to use
your method we can "resume" the simulation
at a different machine state.
No, you fucking idiot.
This simulation is "resumed" at the "return"
instruction.
No, you fucking idiot.
"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."
See above.
I discussed you (not by name) with Claude AI.
It is convinced that you must be a liar.
Right; anything but atually get to grips with some code.
I will fix this by actually adapting a C interpreter
to prove that you are a liar to anyone that knows C.
I tried to do this with x86 yet this proved far
too difficult for even the chief editor of one
of the most prestigious computer science journals.
It is child's play to show that your claims based on
that x86 contraption are incorrect.
When you resume any simulation that cannot possibly
stop running to the exact same total machine state
No, only the state of the simulation is resumed, not
the total machine state.
Maybe you are not familar with operating systems.
When a descheduled or blocked thread is resumed, the entire machine
state doesn't rewind back to the time that thread stopped. Only that
thread's state is restored.
It is obvious you have gaps in your understanding of
concurrent programming.
Ben Bacarisse would confirm that this one also
would never stop running.
That is correct.
But the simulation of a D, which calls a H(D) that returns 0, is
terminating. So for that resumed simulation, we would find that inside
the simulation, the simulated H(D) returns 0 to the simulated D, which executes its simulated return.
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:Reporing on the behavior of DD() executed from
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) 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
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. >>>>>
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.
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/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?
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,089 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 155:08:35 |
| Calls: | 13,921 |
| Calls today: | 2 |
| Files: | 187,021 |
| D/L today: |
3,912 files (989M bytes) |
| Messages: | 2,457,192 |