On 6/13/2025 6:28 AM, Mikko wrote:
On 2025-06-11 14:11:32 +0000, olcott said:
On 6/11/2025 3:29 AM, Mikko wrote:
On 2025-06-10 16:10:49 +0000, olcott said:
On 6/10/2025 7:01 AM, Mikko wrote:
On 2025-06-09 14:46:30 +0000, olcott said:
On 6/9/2025 6:24 AM, Richard Damon wrote:
On 6/8/25 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
*Every rebuttal to this changes the words*
So, you think a partial simulation defines behavior?
Where do you get that LIE from?
void Infinite_Recursion()
{
Infinite_Recursion();
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
I am no so stupid that I require a complete
simulation of a non-terminating input.
Yes you are. You just express your stupidity in another way.
It only takes two simulations of DDD by HHH for HHH
to correctly recognize a non-halting behavior pattern.
Either the pattern or the recognition is incorrect.
DDD correctly simulated by HHH cannot possibly reach its
own "return" statement final halt state. This by itself
*is* complete proof that the input to HHH(DDD) specifies
non-halting behavior.
No, it is not. The words "cannot possibly" are not sufficiently
meaningful to prove anything. HHH does what it does and does
not what it does not. But what it can or cannot do, possiby or
otherwise?
It is required that one have the technical competence of
a first year CS student that knows C to understand that
it is self-evident that the input to HHH(DDD) specifies
behavior such that DDD correctly simulated by HHH cannot
possibly reach its simulated "return" statement.
On 6/13/2025 6:02 AM, Mikko wrote:
On 2025-06-11 14:03:41 +0000, olcott said:
On 6/11/2025 3:20 AM, Mikko wrote:
On 2025-06-10 15:41:33 +0000, olcott said:
On 6/10/2025 6:41 AM, Mikko wrote:
On 2025-06-10 00:47:12 +0000, olcott said:
On 6/9/2025 7:26 PM, Richard Damon wrote:
On 6/9/25 10:43 AM, olcott wrote:
On 6/9/2025 5:31 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 06:15 schreef olcott:
On 6/8/2025 10:42 PM, dbush wrote:
On 6/8/2025 11:39 PM, olcott wrote:There you go.
On 6/8/2025 10:32 PM, dbush wrote:
On 6/8/2025 11:16 PM, olcott wrote:
On 6/8/2025 10:08 PM, dbush wrote:
On 6/8/2025 10:50 PM, olcott wrote:
void DDD()No it's not, as halt deciders / termination analyzers work with algorithms,
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>
That is stupidly counter-factual.
That you think that shows that
My understanding is deeper than yours.
No decider ever takes any algorithm as its input.
But they take a description/specification of an algorithm, >>>>>>>>>>>
which is what is meant in this context.
It turns out that this detail makes a big difference.
And because your HHH does not work with the description/ specification
of an algorithm, by your own admission, you're not working on the >>>>>>>>>>>> halting problem.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.
And HHH fails to see the specification of the x86 instructions. It >>>>>>>>>> aborts before it can see how the program ends.
This is merely a lack of sufficient technical competence
on your part. It is a verified fact that unless the outer
HHH aborts its simulation of DDD that DDD simulated by HHH
the directly executed DDD() and the directly executed HHH()
would never stop running. That you cannot directly see this
is merely your own lack of sufficient technical competence.
And it is a verified fact that you just ignore that if HHH does in fact
abort its simulation of DDD and return 0, then the behavior of the >>>>>>>> input, PER THE ACTUAL DEFINITIONS, is to Halt, and thus HHH is just >>>>>>>> incorrect.
void DDD()
{
HHH(DDD);
return;
}
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?
If HHH is not a decider the question is not interesting.
I switched to the term: "termination analyzer" because halt deciders >>>>> have the impossible task of being all knowing.
The termination problem is in certain sense harder than the halting
problem.
Not at all
That's in another sense in which nothing is harder than impossible.
void DDD()
{
HHH(DDD);
return;
}
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.
It is not a correct termination analyzer if if gives the wrong answer.
*Key verified facts such that disagreement is inherently incorrect*
(a) HHH(DDD) does not correctly report on the behavior of its caller.
(b) Within the theory of computation HHH is not allowed to report
on the behavior of its caller.
(c) HHH(DDD) does correctly report on the behavior that its
input specifies.
On 6/15/2025 4:32 AM, Mikko wrote:
On 2025-06-14 14:07:49 +0000, olcott said:
On 6/13/2025 6:02 AM, Mikko wrote:
On 2025-06-11 14:03:41 +0000, olcott said:
On 6/11/2025 3:20 AM, Mikko wrote:
On 2025-06-10 15:41:33 +0000, olcott said:
On 6/10/2025 6:41 AM, Mikko wrote:
On 2025-06-10 00:47:12 +0000, olcott said:
On 6/9/2025 7:26 PM, Richard Damon wrote:
On 6/9/25 10:43 AM, olcott wrote:
On 6/9/2025 5:31 AM, Fred. Zwarts wrote:And it is a verified fact that you just ignore that if HHH >>>>>>>>>> does in fact abort its simulation of DDD and return 0, then >>>>>>>>>> the behavior of the input, PER THE ACTUAL DEFINITIONS, is to >>>>>>>>>> Halt, and thus HHH is just incorrect.
Op 09.jun.2025 om 06:15 schreef olcott:
On 6/8/2025 10:42 PM, dbush wrote:And HHH fails to see the specification of the x86
On 6/8/2025 11:39 PM, olcott wrote:There you go.
On 6/8/2025 10:32 PM, dbush wrote:But they take a description/specification of an algorithm, >>>>>>>>>>>>>
On 6/8/2025 11:16 PM, olcott wrote:
On 6/8/2025 10:08 PM, dbush wrote:
On 6/8/2025 10:50 PM, olcott wrote:
void DDD()No it's not, as halt deciders / termination analyzers >>>>>>>>>>>>>>>>>> work with algorithms,
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>>>
That is stupidly counter-factual.
That you think that shows that
My understanding is deeper than yours.
No decider ever takes any algorithm as its input. >>>>>>>>>>>>>>
which is what is meant in this context.
It turns out that this detail makes a big difference. >>>>>>>>>>>>>
And because your HHH does not work with the description/ >>>>>>>>>>>>>> specification of an algorithm, by your own admission, >>>>>>>>>>>>>> you're not working on the halting problem.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD. >>>>>>>>>>>>
instructions. It aborts before it can see how the program ends. >>>>>>>>>>>>
This is merely a lack of sufficient technical competence >>>>>>>>>>> on your part. It is a verified fact that unless the outer >>>>>>>>>>> HHH aborts its simulation of DDD that DDD simulated by HHH >>>>>>>>>>> the directly executed DDD() and the directly executed HHH() >>>>>>>>>>> would never stop running. That you cannot directly see this >>>>>>>>>>> is merely your own lack of sufficient technical competence. >>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?
If HHH is not a decider the question is not interesting.
I switched to the term: "termination analyzer" because halt deciders >>>>>>> have the impossible task of being all knowing.
The termination problem is in certain sense harder than the halting >>>>>> problem.
Not at all
That's in another sense in which nothing is harder than impossible.
void DDD()
{
HHH(DDD);
return;
}
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.
It is not a correct termination analyzer if if gives the wrong answer.
*Key verified facts such that disagreement is inherently incorrect*
(a) HHH(DDD) does not correctly report on the behavior of its caller.
True.
(b) Within the theory of computation HHH is not allowed to report
on the behavior of its caller.
False. The theory of computation does not prohibit anything.
*Sure it does*
A termination analyzer / partial halt decider is required
to report on the sequence of state transitions that its
input specifies. It is not allowed to report on anything else.
More
generally, mathematical and scientific theories do not prohibit.
(c) HHH(DDD) does correctly report on the behavior that its
input specifies.
False. The input specifies the behavior that is observed when DDD and
a main that calls DDD are complided and linked with your HHH and with
whatever HHH needs, and then executed. That behaviour is known to halt.
The HHH(DDD) that the executed DDD() calls *IS NOT ITS INPUT*.
Every CS grad should know this.
On 6/15/2025 4:32 AM, Mikko wrote:
On 2025-06-14 14:07:49 +0000, olcott said:
On 6/13/2025 6:02 AM, Mikko wrote:
On 2025-06-11 14:03:41 +0000, olcott said:
On 6/11/2025 3:20 AM, Mikko wrote:
On 2025-06-10 15:41:33 +0000, olcott said:
On 6/10/2025 6:41 AM, Mikko wrote:
On 2025-06-10 00:47:12 +0000, olcott said:
On 6/9/2025 7:26 PM, Richard Damon wrote:
On 6/9/25 10:43 AM, olcott wrote:
On 6/9/2025 5:31 AM, Fred. Zwarts wrote:And it is a verified fact that you just ignore that if HHH does in fact
Op 09.jun.2025 om 06:15 schreef olcott:
On 6/8/2025 10:42 PM, dbush wrote:And HHH fails to see the specification of the x86 instructions. It >>>>>>>>>>>> aborts before it can see how the program ends.
On 6/8/2025 11:39 PM, olcott wrote:There you go.
On 6/8/2025 10:32 PM, dbush wrote:But they take a description/specification of an algorithm, >>>>>>>>>>>>>
On 6/8/2025 11:16 PM, olcott wrote:
On 6/8/2025 10:08 PM, dbush wrote:
On 6/8/2025 10:50 PM, olcott wrote:
void DDD()No it's not, as halt deciders / termination analyzers work with algorithms,
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>>>
That is stupidly counter-factual.
That you think that shows that
My understanding is deeper than yours.
No decider ever takes any algorithm as its input. >>>>>>>>>>>>>>
which is what is meant in this context.
It turns out that this detail makes a big difference. >>>>>>>>>>>>>
And because your HHH does not work with the description/ specification
of an algorithm, by your own admission, you're not working on the
halting problem.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD. >>>>>>>>>>>>
This is merely a lack of sufficient technical competence >>>>>>>>>>> on your part. It is a verified fact that unless the outer >>>>>>>>>>> HHH aborts its simulation of DDD that DDD simulated by HHH >>>>>>>>>>> the directly executed DDD() and the directly executed HHH() >>>>>>>>>>> would never stop running. That you cannot directly see this >>>>>>>>>>> is merely your own lack of sufficient technical competence. >>>>>>>>>>
abort its simulation of DDD and return 0, then the behavior of the >>>>>>>>>> input, PER THE ACTUAL DEFINITIONS, is to Halt, and thus HHH is just >>>>>>>>>> incorrect.
void DDD()
{
HHH(DDD);
return;
}
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?
If HHH is not a decider the question is not interesting.
I switched to the term: "termination analyzer" because halt deciders >>>>>>> have the impossible task of being all knowing.
The termination problem is in certain sense harder than the halting >>>>>> problem.
Not at all
That's in another sense in which nothing is harder than impossible.
void DDD()
{
HHH(DDD);
return;
}
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.
It is not a correct termination analyzer if if gives the wrong answer.
*Key verified facts such that disagreement is inherently incorrect*
(a) HHH(DDD) does not correctly report on the behavior of its caller.
True.
(b) Within the theory of computation HHH is not allowed to report
on the behavior of its caller.
False. The theory of computation does not prohibit anything.
*Sure it does*
A termination analyzer / partial halt decider is required
to report on the sequence of state transitions that its
input specifies. It is not allowed to report on anything else.
On 6/15/2025 3:44 AM, Fred. Zwarts wrote:
Op 14.jun.2025 om 16:07 schreef olcott:
On 6/13/2025 6:02 AM, Mikko wrote:
On 2025-06-11 14:03:41 +0000, olcott said:
On 6/11/2025 3:20 AM, Mikko wrote:
On 2025-06-10 15:41:33 +0000, olcott said:
On 6/10/2025 6:41 AM, Mikko wrote:
On 2025-06-10 00:47:12 +0000, olcott said:
On 6/9/2025 7:26 PM, Richard Damon wrote:
On 6/9/25 10:43 AM, olcott wrote:
On 6/9/2025 5:31 AM, Fred. Zwarts wrote:And it is a verified fact that you just ignore that if HHH does in fact
Op 09.jun.2025 om 06:15 schreef olcott:
On 6/8/2025 10:42 PM, dbush wrote:And HHH fails to see the specification of the x86 instructions. It >>>>>>>>>>>> aborts before it can see how the program ends.
On 6/8/2025 11:39 PM, olcott wrote:There you go.
On 6/8/2025 10:32 PM, dbush wrote:But they take a description/specification of an algorithm, >>>>>>>>>>>>>
On 6/8/2025 11:16 PM, olcott wrote:
On 6/8/2025 10:08 PM, dbush wrote:
On 6/8/2025 10:50 PM, olcott wrote:
void DDD()No it's not, as halt deciders / termination analyzers work with algorithms,
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>>>
That is stupidly counter-factual.
That you think that shows that
My understanding is deeper than yours.
No decider ever takes any algorithm as its input. >>>>>>>>>>>>>>
which is what is meant in this context.
It turns out that this detail makes a big difference. >>>>>>>>>>>>>
And because your HHH does not work with the description/ specification
of an algorithm, by your own admission, you're not working on the
halting problem.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD. >>>>>>>>>>>>
This is merely a lack of sufficient technical competence >>>>>>>>>>> on your part. It is a verified fact that unless the outer >>>>>>>>>>> HHH aborts its simulation of DDD that DDD simulated by HHH >>>>>>>>>>> the directly executed DDD() and the directly executed HHH() >>>>>>>>>>> would never stop running. That you cannot directly see this >>>>>>>>>>> is merely your own lack of sufficient technical competence. >>>>>>>>>>
abort its simulation of DDD and return 0, then the behavior of the >>>>>>>>>> input, PER THE ACTUAL DEFINITIONS, is to Halt, and thus HHH is just >>>>>>>>>> incorrect.
void DDD()
{
HHH(DDD);
return;
}
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?
If HHH is not a decider the question is not interesting.
I switched to the term: "termination analyzer" because halt deciders >>>>>>> have the impossible task of being all knowing.
The termination problem is in certain sense harder than the halting >>>>>> problem.
Not at all
That's in another sense in which nothing is harder than impossible.
void DDD()
{
HHH(DDD);
return;
}
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.
It is not a correct termination analyzer if if gives the wrong answer.
*Key verified facts such that disagreement is inherently incorrect*
(a) HHH(DDD) does not correctly report on the behavior of its caller.
Irrelevant. HHH should decide about the program specified in the input,
whether or not it is the same code used by the caller.
In other words you do not understand that a partial
halt decider is not allowed to report on the behavior
of its caller and only allowed to report on the behavior
specified by the sequence of state transitions specified
by its input.
On 6/15/2025 4:39 AM, Mikko wrote:
On 2025-06-14 14:17:46 +0000, olcott said:
On 6/13/2025 6:28 AM, Mikko wrote:
On 2025-06-11 14:11:32 +0000, olcott said:
On 6/11/2025 3:29 AM, Mikko wrote:
On 2025-06-10 16:10:49 +0000, olcott said:
On 6/10/2025 7:01 AM, Mikko wrote:
On 2025-06-09 14:46:30 +0000, olcott said:
On 6/9/2025 6:24 AM, Richard Damon wrote:
On 6/8/25 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its
*simulated "return" instruction final halt state*
*Every rebuttal to this changes the words*
So, you think a partial simulation defines behavior?
Where do you get that LIE from?
void Infinite_Recursion()
{
Infinite_Recursion();
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
I am no so stupid that I require a complete
simulation of a non-terminating input.
Yes you are. You just express your stupidity in another way.
It only takes two simulations of DDD by HHH for HHH
to correctly recognize a non-halting behavior pattern.
Either the pattern or the recognition is incorrect.
DDD correctly simulated by HHH cannot possibly reach its
own "return" statement final halt state. This by itself
*is* complete proof that the input to HHH(DDD) specifies
non-halting behavior.
No, it is not. The words "cannot possibly" are not sufficiently
meaningful to prove anything. HHH does what it does and does
not what it does not. But what it can or cannot do, possiby or
otherwise?
It is required that one have the technical competence of
a first year CS student that knows C to understand that
it is self-evident that the input to HHH(DDD) specifies
behavior such that DDD correctly simulated by HHH cannot
possibly reach its simulated "return" statement.
The meaning of "self-evident" excludes all requirements of
any technical competence.
The meaning of "cannot possibly", if there is any, is too far from
clear that a sentence containing it could be self-evident.
void DDD()
{
HHH(DDD);
return;
}
Where DDD is correctly simulated by HHH is
merely a more complex form of this same pattern:
void H()
{
D();
}
void D()
{
H();
}
On 6/16/2025 6:40 AM, Mikko wrote:
On 2025-06-15 13:57:01 +0000, olcott said:
On 6/15/2025 3:44 AM, Fred. Zwarts wrote:
Op 14.jun.2025 om 16:07 schreef olcott:
On 6/13/2025 6:02 AM, Mikko wrote:Irrelevant. HHH should decide about the program specified in the
On 2025-06-11 14:03:41 +0000, olcott said:
On 6/11/2025 3:20 AM, Mikko wrote:
On 2025-06-10 15:41:33 +0000, olcott said:
On 6/10/2025 6:41 AM, Mikko wrote:
On 2025-06-10 00:47:12 +0000, olcott said:
On 6/9/2025 7:26 PM, Richard Damon wrote:
On 6/9/25 10:43 AM, olcott wrote:
On 6/9/2025 5:31 AM, Fred. Zwarts wrote:And it is a verified fact that you just ignore that if HHH >>>>>>>>>>>> does in fact abort its simulation of DDD and return 0, then >>>>>>>>>>>> the behavior of the input, PER THE ACTUAL DEFINITIONS, is to >>>>>>>>>>>> Halt, and thus HHH is just incorrect.
Op 09.jun.2025 om 06:15 schreef olcott:
On 6/8/2025 10:42 PM, dbush wrote:And HHH fails to see the specification of the x86
On 6/8/2025 11:39 PM, olcott wrote:There you go.
On 6/8/2025 10:32 PM, dbush wrote:But they take a description/specification of an algorithm, >>>>>>>>>>>>>>>
On 6/8/2025 11:16 PM, olcott wrote:
On 6/8/2025 10:08 PM, dbush wrote:
On 6/8/2025 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
No it's not, as halt deciders / termination >>>>>>>>>>>>>>>>>>>> analyzers work with algorithms,
That is stupidly counter-factual.
That you think that shows that
My understanding is deeper than yours.
No decider ever takes any algorithm as its input. >>>>>>>>>>>>>>>>
which is what is meant in this context.
It turns out that this detail makes a big difference. >>>>>>>>>>>>>>>
And because your HHH does not work with the description/ >>>>>>>>>>>>>>>> specification of an algorithm, by your own admission, >>>>>>>>>>>>>>>> you're not working on the halting problem.
HHH(DDD) takes a finite string of x86 instructions >>>>>>>>>>>>>>> that specify that HHH simulates itself simulating DDD. >>>>>>>>>>>>>>
instructions. It aborts before it can see how the program >>>>>>>>>>>>>> ends.
This is merely a lack of sufficient technical competence >>>>>>>>>>>>> on your part. It is a verified fact that unless the outer >>>>>>>>>>>>> HHH aborts its simulation of DDD that DDD simulated by HHH >>>>>>>>>>>>> the directly executed DDD() and the directly executed HHH() >>>>>>>>>>>>> would never stop running. That you cannot directly see this >>>>>>>>>>>>> is merely your own lack of sufficient technical competence. >>>>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?
If HHH is not a decider the question is not interesting.
I switched to the term: "termination analyzer" because halt
deciders
have the impossible task of being all knowing.
The termination problem is in certain sense harder than the halting >>>>>>>> problem.
Not at all
That's in another sense in which nothing is harder than impossible. >>>>>>
void DDD()
{
HHH(DDD);
return;
}
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.
It is not a correct termination analyzer if if gives the wrong
answer.
*Key verified facts such that disagreement is inherently incorrect*
(a) HHH(DDD) does not correctly report on the behavior of its caller. >>>>
input, whether or not it is the same code used by the caller.
In other words you do not understand that a partial
halt decider is not allowed to report on the behavior
of its caller and only allowed to report on the behavior
specified by the sequence of state transitions specified
by its input.
It is not allowed to report incorrectly. There are no prohibitions
against correct reporting.
And you do not understand which is which.
int main()
{
DDD(); // Calls HHH(DDD) that cannot report on the
} // behavior of its caller because it cannot
// see its caller. Its caller could have been main()
On 6/16/2025 6:50 AM, Mikko wrote:
On 2025-06-15 15:13:44 +0000, olcott said:
On 6/15/2025 4:39 AM, Mikko wrote:
On 2025-06-14 14:17:46 +0000, olcott said:
On 6/13/2025 6:28 AM, Mikko wrote:
On 2025-06-11 14:11:32 +0000, olcott said:
On 6/11/2025 3:29 AM, Mikko wrote:
On 2025-06-10 16:10:49 +0000, olcott said:
On 6/10/2025 7:01 AM, Mikko wrote:
On 2025-06-09 14:46:30 +0000, olcott said:
On 6/9/2025 6:24 AM, Richard Damon wrote:
On 6/8/25 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>> *simulated "return" instruction final halt state*
*Every rebuttal to this changes the words*
So, you think a partial simulation defines behavior?
Where do you get that LIE from?
void Infinite_Recursion()
{
Infinite_Recursion();
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
I am no so stupid that I require a complete
simulation of a non-terminating input.
Yes you are. You just express your stupidity in another way. >>>>>>>>>>
It only takes two simulations of DDD by HHH for HHH
to correctly recognize a non-halting behavior pattern.
Either the pattern or the recognition is incorrect.
DDD correctly simulated by HHH cannot possibly reach its
own "return" statement final halt state. This by itself
*is* complete proof that the input to HHH(DDD) specifies
non-halting behavior.
No, it is not. The words "cannot possibly" are not sufficiently
meaningful to prove anything. HHH does what it does and does
not what it does not. But what it can or cannot do, possiby or
otherwise?
It is required that one have the technical competence of
a first year CS student that knows C to understand that
it is self-evident that the input to HHH(DDD) specifies
behavior such that DDD correctly simulated by HHH cannot
possibly reach its simulated "return" statement.
The meaning of "self-evident" excludes all requirements of
any technical competence.
The meaning of "cannot possibly", if there is any, is too far from
clear that a sentence containing it could be self-evident.
void DDD()
{
HHH(DDD);
return;
}
Where DDD is correctly simulated by HHH is
merely a more complex form of this same pattern:
void H()
{
D();
}
void D()
{
H();
}
Nice to see that you don't disagree.
But I'm afraid you may forget.
I have never seen any agreement form you for anything
that I have ever said.
If you agree that the input to HHH(DDD) specifies
a non-halting sequence of configurations we can move
on to the next step.
On 6/16/2025 6:46 AM, Mikko wrote:
On 2025-06-15 15:00:02 +0000, olcott said:
On 6/15/2025 4:32 AM, Mikko wrote:
On 2025-06-14 14:07:49 +0000, olcott said:
On 6/13/2025 6:02 AM, Mikko wrote:True.
On 2025-06-11 14:03:41 +0000, olcott said:
On 6/11/2025 3:20 AM, Mikko wrote:
On 2025-06-10 15:41:33 +0000, olcott said:
On 6/10/2025 6:41 AM, Mikko wrote:
On 2025-06-10 00:47:12 +0000, olcott said:
On 6/9/2025 7:26 PM, Richard Damon wrote:
On 6/9/25 10:43 AM, olcott wrote:
On 6/9/2025 5:31 AM, Fred. Zwarts wrote:And it is a verified fact that you just ignore that if HHH >>>>>>>>>>>> does in fact abort its simulation of DDD and return 0, then >>>>>>>>>>>> the behavior of the input, PER THE ACTUAL DEFINITIONS, is to >>>>>>>>>>>> Halt, and thus HHH is just incorrect.
Op 09.jun.2025 om 06:15 schreef olcott:
On 6/8/2025 10:42 PM, dbush wrote:And HHH fails to see the specification of the x86
On 6/8/2025 11:39 PM, olcott wrote:There you go.
On 6/8/2025 10:32 PM, dbush wrote:But they take a description/specification of an algorithm, >>>>>>>>>>>>>>>
On 6/8/2025 11:16 PM, olcott wrote:
On 6/8/2025 10:08 PM, dbush wrote:
On 6/8/2025 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer >>>>>>>>>>>>>>>>>>>>> HHH(DDD)
No it's not, as halt deciders / termination >>>>>>>>>>>>>>>>>>>> analyzers work with algorithms,
That is stupidly counter-factual.
That you think that shows that
My understanding is deeper than yours.
No decider ever takes any algorithm as its input. >>>>>>>>>>>>>>>>
which is what is meant in this context.
It turns out that this detail makes a big difference. >>>>>>>>>>>>>>>
And because your HHH does not work with the description/ >>>>>>>>>>>>>>>> specification of an algorithm, by your own admission, >>>>>>>>>>>>>>>> you're not working on the halting problem.
HHH(DDD) takes a finite string of x86 instructions >>>>>>>>>>>>>>> that specify that HHH simulates itself simulating DDD. >>>>>>>>>>>>>>
instructions. It aborts before it can see how the program >>>>>>>>>>>>>> ends.
This is merely a lack of sufficient technical competence >>>>>>>>>>>>> on your part. It is a verified fact that unless the outer >>>>>>>>>>>>> HHH aborts its simulation of DDD that DDD simulated by HHH >>>>>>>>>>>>> the directly executed DDD() and the directly executed HHH() >>>>>>>>>>>>> would never stop running. That you cannot directly see this >>>>>>>>>>>>> is merely your own lack of sufficient technical competence. >>>>>>>>>>>>
void DDD()
{
HHH(DDD);
return;
}
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?
If HHH is not a decider the question is not interesting.
I switched to the term: "termination analyzer" because halt
deciders
have the impossible task of being all knowing.
The termination problem is in certain sense harder than the halting >>>>>>>> problem.
Not at all
That's in another sense in which nothing is harder than impossible. >>>>>>
void DDD()
{
HHH(DDD);
return;
}
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.
It is not a correct termination analyzer if if gives the wrong
answer.
*Key verified facts such that disagreement is inherently incorrect*
(a) HHH(DDD) does not correctly report on the behavior of its caller. >>>>
(b) Within the theory of computation HHH is not allowed to report
on the behavior of its caller.
False. The theory of computation does not prohibit anything.
*Sure it does*
A termination analyzer / partial halt decider is required
to report on the sequence of state transitions that its
input specifies. It is not allowed to report on anything else.
The word "partial" means that it is not required to report.
But if it does report it is required to report correctly whether
the computation described by the input halts if fully executed.
An incorret report is not allowed but a lack of report is.
Its input could be described as performing some
arbitrary unspecified sequence of steps, thus
"described" is an insufficiently precise term.
To correct that error I say that the termination
analyzer must report on the behavior specified
by the sequence of steps of its input.
void DDD()
{
HHH(DDD);
return;
}
When one or more instructions of DDD are correctly
simulated by ANY simulating termination analyzer HHH
then this correctly simulated DDD never reaches its
simulated "return" statement final halt state.
Thus no DDD of any HHH/DDD pair halts when "halts"
is defined as reaching a final halt state.
Since this *is* a verified fact any disagreement
is inherently incorrect.
On 6/16/2025 6:50 AM, Mikko wrote:
On 2025-06-15 15:13:44 +0000, olcott said:
On 6/15/2025 4:39 AM, Mikko wrote:
On 2025-06-14 14:17:46 +0000, olcott said:
On 6/13/2025 6:28 AM, Mikko wrote:
On 2025-06-11 14:11:32 +0000, olcott said:
On 6/11/2025 3:29 AM, Mikko wrote:
On 2025-06-10 16:10:49 +0000, olcott said:
On 6/10/2025 7:01 AM, Mikko wrote:
On 2025-06-09 14:46:30 +0000, olcott said:
On 6/9/2025 6:24 AM, Richard Damon wrote:
On 6/8/25 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>> *simulated "return" instruction final halt state*
*Every rebuttal to this changes the words*
So, you think a partial simulation defines behavior?
Where do you get that LIE from?
void Infinite_Recursion()
{
Infinite_Recursion();
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
I am no so stupid that I require a complete
simulation of a non-terminating input.
Yes you are. You just express your stupidity in another way. >>>>>>>>>>
It only takes two simulations of DDD by HHH for HHH
to correctly recognize a non-halting behavior pattern.
Either the pattern or the recognition is incorrect.
DDD correctly simulated by HHH cannot possibly reach its
own "return" statement final halt state. This by itself
*is* complete proof that the input to HHH(DDD) specifies
non-halting behavior.
No, it is not. The words "cannot possibly" are not sufficiently
meaningful to prove anything. HHH does what it does and does
not what it does not. But what it can or cannot do, possiby or
otherwise?
It is required that one have the technical competence of
a first year CS student that knows C to understand that
it is self-evident that the input to HHH(DDD) specifies
behavior such that DDD correctly simulated by HHH cannot
possibly reach its simulated "return" statement.
The meaning of "self-evident" excludes all requirements of
any technical competence.
The meaning of "cannot possibly", if there is any, is too far from
clear that a sentence containing it could be self-evident.
void DDD()
{
HHH(DDD);
return;
}
Where DDD is correctly simulated by HHH is
merely a more complex form of this same pattern:
void H()
{
D();
}
void D()
{
H();
}
Nice to see that you don't disagree.
But I'm afraid you may forget.
I have never seen any agreement form you for anything
that I have ever said.
If you agree that the input to HHH(DDD) specifies
a non-halting sequence of configurations we can move
on to the next step.
On 6/16/2025 6:40 AM, Mikko wrote:
On 2025-06-15 13:57:01 +0000, olcott said:
On 6/15/2025 3:44 AM, Fred. Zwarts wrote:
Op 14.jun.2025 om 16:07 schreef olcott:
On 6/13/2025 6:02 AM, Mikko wrote:Irrelevant. HHH should decide about the program specified in the input, >>>> whether or not it is the same code used by the caller.
On 2025-06-11 14:03:41 +0000, olcott said:*Key verified facts such that disagreement is inherently incorrect*
On 6/11/2025 3:20 AM, Mikko wrote:
On 2025-06-10 15:41:33 +0000, olcott said:
On 6/10/2025 6:41 AM, Mikko wrote:
On 2025-06-10 00:47:12 +0000, olcott said:
On 6/9/2025 7:26 PM, Richard Damon wrote:
On 6/9/25 10:43 AM, olcott wrote:
On 6/9/2025 5:31 AM, Fred. Zwarts wrote:And it is a verified fact that you just ignore that if HHH does in fact
Op 09.jun.2025 om 06:15 schreef olcott:
On 6/8/2025 10:42 PM, dbush wrote:And HHH fails to see the specification of the x86 instructions. It
On 6/8/2025 11:39 PM, olcott wrote:There you go.
On 6/8/2025 10:32 PM, dbush wrote:But they take a description/specification of an algorithm, >>>>>>>>>>>>>>>
On 6/8/2025 11:16 PM, olcott wrote:
On 6/8/2025 10:08 PM, dbush wrote:
On 6/8/2025 10:50 PM, olcott wrote:
void DDD()No it's not, as halt deciders / termination analyzers work with algorithms,
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>>>>>>>
That is stupidly counter-factual.
That you think that shows that
My understanding is deeper than yours.
No decider ever takes any algorithm as its input. >>>>>>>>>>>>>>>>
which is what is meant in this context.
It turns out that this detail makes a big difference. >>>>>>>>>>>>>>>
And because your HHH does not work with the description/ specification
of an algorithm, by your own admission, you're not working on the
halting problem.
HHH(DDD) takes a finite string of x86 instructions >>>>>>>>>>>>>>> that specify that HHH simulates itself simulating DDD. >>>>>>>>>>>>>>
aborts before it can see how the program ends.
This is merely a lack of sufficient technical competence >>>>>>>>>>>>> on your part. It is a verified fact that unless the outer >>>>>>>>>>>>> HHH aborts its simulation of DDD that DDD simulated by HHH >>>>>>>>>>>>> the directly executed DDD() and the directly executed HHH() >>>>>>>>>>>>> would never stop running. That you cannot directly see this >>>>>>>>>>>>> is merely your own lack of sufficient technical competence. >>>>>>>>>>>>
abort its simulation of DDD and return 0, then the behavior of the >>>>>>>>>>>> input, PER THE ACTUAL DEFINITIONS, is to Halt, and thus HHH is just
incorrect.
void DDD()
{
HHH(DDD);
return;
}
How the f-ck does DDD correctly simulated by HHH
reach its own "return" statement final halt state?
If HHH is not a decider the question is not interesting.
I switched to the term: "termination analyzer" because halt deciders >>>>>>>>> have the impossible task of being all knowing.
The termination problem is in certain sense harder than the halting >>>>>>>> problem.
Not at all
That's in another sense in which nothing is harder than impossible. >>>>>>
void DDD()
{
HHH(DDD);
return;
}
If HHH only determines non-halting correctly for the
above input and gets the wrong answer on everything
else then HHH *is* a correct termination analyzer.
It is not a correct termination analyzer if if gives the wrong answer. >>>>>
(a) HHH(DDD) does not correctly report on the behavior of its caller. >>>>
In other words you do not understand that a partial
halt decider is not allowed to report on the behavior
of its caller and only allowed to report on the behavior
specified by the sequence of state transitions specified
by its input.
It is not allowed to report incorrectly. There are no prohibitions
against correct reporting.
And you do not understand which is which.
On 6/17/2025 4:41 AM, Mikko wrote:
On 2025-06-16 21:11:36 +0000, olcott said:
On 6/16/2025 6:50 AM, Mikko wrote:
On 2025-06-15 15:13:44 +0000, olcott said:
On 6/15/2025 4:39 AM, Mikko wrote:
On 2025-06-14 14:17:46 +0000, olcott said:
On 6/13/2025 6:28 AM, Mikko wrote:
On 2025-06-11 14:11:32 +0000, olcott said:
On 6/11/2025 3:29 AM, Mikko wrote:
On 2025-06-10 16:10:49 +0000, olcott said:
On 6/10/2025 7:01 AM, Mikko wrote:
On 2025-06-09 14:46:30 +0000, olcott said:
On 6/9/2025 6:24 AM, Richard Damon wrote:
On 6/8/25 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>>>> *simulated "return" instruction final halt state* >>>>>>>>>>>>>>>
*Every rebuttal to this changes the words*
So, you think a partial simulation defines behavior? >>>>>>>>>>>>>>
Where do you get that LIE from?
void Infinite_Recursion()
{
Infinite_Recursion();
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
I am no so stupid that I require a complete
simulation of a non-terminating input.
Yes you are. You just express your stupidity in another way. >>>>>>>>>>>>
It only takes two simulations of DDD by HHH for HHH
to correctly recognize a non-halting behavior pattern.
Either the pattern or the recognition is incorrect.
DDD correctly simulated by HHH cannot possibly reach its
own "return" statement final halt state. This by itself
*is* complete proof that the input to HHH(DDD) specifies
non-halting behavior.
No, it is not. The words "cannot possibly" are not sufficiently >>>>>>>> meaningful to prove anything. HHH does what it does and does
not what it does not. But what it can or cannot do, possiby or >>>>>>>> otherwise?
It is required that one have the technical competence of
a first year CS student that knows C to understand that
it is self-evident that the input to HHH(DDD) specifies
behavior such that DDD correctly simulated by HHH cannot
possibly reach its simulated "return" statement.
The meaning of "self-evident" excludes all requirements of
any technical competence.
The meaning of "cannot possibly", if there is any, is too far from >>>>>> clear that a sentence containing it could be self-evident.
void DDD()
{
HHH(DDD);
return;
}
Where DDD is correctly simulated by HHH is
merely a more complex form of this same pattern:
void H()
{
D();
}
void D()
{
H();
}
Nice to see that you don't disagree.
But I'm afraid you may forget.
I have never seen any agreement form you for anything
that I have ever said.
You rarely say anything one could agree without looking stupid.
It seems to me that you are only interested in rebuttal.
That is not an honest dialogue.
If you agree that the input to HHH(DDD) specifies
a non-halting sequence of configurations we can move
on to the next step.
It does not make sense to say "a non-halting sequence of configurations".
That sequence cannot halt because it is not running. If you mean that
the sequence is infinitely long then say so.
In other words you baselessly reject the whole
notion of simulating termination analyzers.
That this rejection is baseless seems dishonest.
On 6/17/2025 4:41 AM, Mikko wrote:
On 2025-06-16 21:11:36 +0000, olcott said:
On 6/16/2025 6:50 AM, Mikko wrote:
On 2025-06-15 15:13:44 +0000, olcott said:
On 6/15/2025 4:39 AM, Mikko wrote:
On 2025-06-14 14:17:46 +0000, olcott said:
On 6/13/2025 6:28 AM, Mikko wrote:
On 2025-06-11 14:11:32 +0000, olcott said:
On 6/11/2025 3:29 AM, Mikko wrote:
On 2025-06-10 16:10:49 +0000, olcott said:
On 6/10/2025 7:01 AM, Mikko wrote:
On 2025-06-09 14:46:30 +0000, olcott said:
On 6/9/2025 6:24 AM, Richard Damon wrote:
On 6/8/25 10:50 PM, olcott wrote:
void DDD()
{
HHH(DDD);
return;
}
The *input* to simulating termination analyzer HHH(DDD) >>>>>>>>>>>>>>> specifies recursive simulation that can never reach its >>>>>>>>>>>>>>> *simulated "return" instruction final halt state* >>>>>>>>>>>>>>>
*Every rebuttal to this changes the words*
So, you think a partial simulation defines behavior? >>>>>>>>>>>>>>
Where do you get that LIE from?
void Infinite_Recursion()
{
Infinite_Recursion();
}
void Infinite_Loop()
{
HERE: goto HERE;
return;
}
I am no so stupid that I require a complete
simulation of a non-terminating input.
Yes you are. You just express your stupidity in another way. >>>>>>>>>>>>
It only takes two simulations of DDD by HHH for HHH
to correctly recognize a non-halting behavior pattern.
Either the pattern or the recognition is incorrect.
DDD correctly simulated by HHH cannot possibly reach its
own "return" statement final halt state. This by itself
*is* complete proof that the input to HHH(DDD) specifies
non-halting behavior.
No, it is not. The words "cannot possibly" are not sufficiently >>>>>>>> meaningful to prove anything. HHH does what it does and does
not what it does not. But what it can or cannot do, possiby or >>>>>>>> otherwise?
It is required that one have the technical competence of
a first year CS student that knows C to understand that
it is self-evident that the input to HHH(DDD) specifies
behavior such that DDD correctly simulated by HHH cannot
possibly reach its simulated "return" statement.
The meaning of "self-evident" excludes all requirements of
any technical competence.
The meaning of "cannot possibly", if there is any, is too far from >>>>>> clear that a sentence containing it could be self-evident.
void DDD()
{
HHH(DDD);
return;
}
Where DDD is correctly simulated by HHH is
merely a more complex form of this same pattern:
void H()
{
D();
}
void D()
{
H();
}
Nice to see that you don't disagree.
But I'm afraid you may forget.
I have never seen any agreement form you for anything
that I have ever said.
You rarely say anything one could agree without looking stupid.
It seems to me that you are only interested in rebuttal.
That is not an honest dialogue.
If you agree that the input to HHH(DDD) specifies
a non-halting sequence of configurations we can move
on to the next step.
It does not make sense to say "a non-halting sequence of configurations".
That sequence cannot halt because it is not running. If you mean that
the sequence is infinitely long then say so.
In other words you baselessly reject the whole
notion of simulating termination analyzers.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 54:01:28 |
| Calls: | 10,397 |
| Calls today: | 5 |
| Files: | 14,067 |
| Messages: | 6,417,407 |
| Posted today: | 1 |