On 6/10/2025 11:09 AM, Mike Terry wrote:
On 10/06/2025 12:41, 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:
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,
There you go.
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.
If HHH is a deider it returns. The first insturunction
after the return terminates the execution of DDD.
But then DDD *simulated by HHH* does is not simulated as far as its own return statement. In fact
zero steps of DDD are simulated.
Since I have shown you the execution trace of DDD simulated
by HHH many times it is gross negligence that you say that
"zero steps of DDD are simulated."
On 10/06/2025 17:17, olcott wrote:
On 6/10/2025 11:09 AM, Mike Terry wrote:
On 10/06/2025 12:41, 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:
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,
There you go.
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.
If HHH is a deider it returns. The first insturunction
after the return terminates the execution of DDD.
But then DDD *simulated by HHH* does is not simulated as far as its own return statement. In
fact zero steps of DDD are simulated.
Since I have shown you the execution trace of DDD simulated
by HHH many times it is gross negligence that you say that
"zero steps of DDD are simulated."
Upon closer inspection it seems I misread what Mikko was saying. I misread that he was suggesting
an HHH which returned straight away. So just ignore my "zero steps" remark.
My other remarks look right:
- But then DDD *simulated by HHH* is not simulated as far as its own return statement.
HINT: I'm agreeing with you.
HINT: Mikko, Fred and Richard have all also agreed with that statement,
Nobody has agreed that that implies that DDD halts. <=== THAT is your disagreement.
You're welcome.
- Of course, DDD directly executed will reach its own return statement,
so it is true that this DDD halts...
Mike.
On 6/10/2025 11:42 AM, Mike Terry wrote:
On 10/06/2025 17:17, olcott wrote:
On 6/10/2025 11:09 AM, Mike Terry wrote:
On 10/06/2025 12:41, 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.
If HHH is a deider it returns. The first insturunction
after the return terminates the execution of DDD.
But then DDD *simulated by HHH* does is not simulated as far as its
own return statement. In fact zero steps of DDD are simulated.
Since I have shown you the execution trace of DDD simulated
by HHH many times it is gross negligence that you say that
"zero steps of DDD are simulated."
Upon closer inspection it seems I misread what Mikko was saying. I
misread that he was suggesting an HHH which returned straight away.
So just ignore my "zero steps" remark.
That is great. I continue to trust that you are honest
because of all of the evidence that you provided showing
a very deep and correct understanding of my work.
My other remarks look right:
-Â Â But then DDD *simulated by HHH* is not simulated as far as its own
return statement.
    HINT: I'm agreeing with you.
    HINT: Mikko, Fred and Richard have all also agreed with that
statement,
           Nobody has agreed that that implies that DDD halts. <===
THAT is your disagreement.
           You're welcome.
-Â Â Of course, DDD directly executed will reach its own return statement, >> Â Â Â Â so it is true that this DDD halts...
Mike.
The input to HHH(DDD) specifies non-halting behavior.
int main()
{
 DDD(); // calls HHH(DDD)
}
The HHH(DDD) that DDD() calls cannot report on the
behavior of its caller because it can't even see its
caller. Its caller could have been main() and HHH(DDD)
has no way to see this.
We could define the requirements for an algorithm
to correctly predict the name of president of the
United States 4 years from now and its only input
is a single integer value.
This could not be computable yet does not show any
actual limitation to computer science. Likewise for
a termination analyzer that is required to report
on the behavior of its caller.
On 6/10/2025 2:00 PM, Richard Damon wrote:
On 6/10/25 1:36 PM, olcott wrote:
On 6/10/2025 11:42 AM, Mike Terry wrote:
On 10/06/2025 17:17, olcott wrote:
On 6/10/2025 11:09 AM, Mike Terry wrote:
On 10/06/2025 12:41, 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
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. >>>>>>>>>
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.
If HHH is a deider it returns. The first insturunction
after the return terminates the execution of DDD.
But then DDD *simulated by HHH* does is not simulated as far as
its own return statement. In fact zero steps of DDD are simulated. >>>>>>
Since I have shown you the execution trace of DDD simulated
by HHH many times it is gross negligence that you say that
"zero steps of DDD are simulated."
Upon closer inspection it seems I misread what Mikko was saying. I
misread that he was suggesting an HHH which returned straight away.
So just ignore my "zero steps" remark.
That is great. I continue to trust that you are honest
because of all of the evidence that you provided showing
a very deep and correct understanding of my work.
My other remarks look right:
-Â Â But then DDD *simulated by HHH* is not simulated as far as its
own return statement.
    HINT: I'm agreeing with you.
    HINT: Mikko, Fred and Richard have all also agreed with that >>>> statement,
           Nobody has agreed that that implies that DDD halts. <===
THAT is your disagreement.
           You're welcome.
-Â Â Of course, DDD directly executed will reach its own return
statement,
    so it is true that this DDD halts...
Mike.
The input to HHH(DDD) specifies non-halting behavior.
int main()
{
  DDD(); // calls HHH(DDD)
}
The HHH(DDD) that DDD() calls cannot report on the
behavior of its caller because it can't even see its
caller. Its caller could have been main() and HHH(DDD)
has no way to see this.
Right, so that is why it needs to report on the behavior of the
program DDD, regardless of whether it is its caller or not.
It must report on the behavior that the input to HHH(DDD) specifies.
The input to HHH(DDD) specifies that HHH simulates DDD and then
simulates itself simulating DDD.
I guess you are saying that it is just IMPOSSIBLE to ask a decider
about programs, since it can't "see" the actual execution of it.
STUPID.
HHH(DDD) does correctly reject its input because
its input would never stop running unless aborted.
This remains true even when its input is construed
to include HHH() and everything that HHH calls.
We could define the requirements for an algorithm
to correctly predict the name of president of the
United States 4 years from now and its only input
is a single integer value.
That would be an error.
Likewise with the requirement that a halt decider
report on the behavior of the direct execution of
DDD() which is its own caller.
On 6/10/2025 1:22 PM, Mike Terry wrote:
On 10/06/2025 17:42, Mike Terry wrote:
On 10/06/2025 17:17, olcott wrote:
On 6/10/2025 11:09 AM, Mike Terry wrote:
On 10/06/2025 12:41, 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.
If HHH is a deider it returns. The first insturunction
after the return terminates the execution of DDD.
But then DDD *simulated by HHH* does is not simulated as far as its
own return statement. In fact zero steps of DDD are simulated.
Since I have shown you the execution trace of DDD simulated
by HHH many times it is gross negligence that you say that
"zero steps of DDD are simulated."
Upon closer inspection it seems I misread what Mikko was saying. I
misread that he was suggesting an HHH which returned straight away.
So just ignore my "zero steps" remark.
My other remarks look right:
-Â Â But then DDD *simulated by HHH* is not simulated as far as its
own return statement.
    HINT: I'm agreeing with you.
    HINT: Mikko, Fred and Richard have all also agreed with that
statement,
           Nobody has agreed that that implies that DDD halts. <===
THAT is your disagreement.
           You're welcome.
LOL, oh dear, of course I meant:
              Nobody has agreed that that implies that DDD /never/
halts. <=== THAT is
              your disagreement.
Infinite_Loop()
{
 HERE: goto HERE;
 return;
}
Yet most people here don't know that halts means
reaching the simulated "return" statement final
halt state.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 546 |
Nodes: | 16 (0 / 16) |
Uptime: | 163:19:17 |
Calls: | 10,385 |
Calls today: | 2 |
Files: | 14,057 |
Messages: | 6,416,510 |