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*
On 6/8/2025 10:54 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
On 6/8/2025 10:31 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
void DDD()Do not imply that I support your claims.
{
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*
I am not implying anything. I am directly stating
that you have agreed that when DDD is correctly simulated
by HHH that it cannot possibly reach its own simulated
"return" instruction and terminate normally.
Endless recursion is endless recursion. Correctly simulated endless
recursion is endless recursion.
Great. No one else besides you and I agree that DDD
correctly simulated by HHH cannot possibly reach its
*simulated "return" instruction final halt state*
This has no useful or interesting
consequences. Do you agree?
It is very useful because it is isomorphic to this:
(The standard Halting Problem counter-example input)
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
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()
{
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.
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.
There are more steps, I don't want to overwhelm you.
On 09/06/2025 20:54, dbush wrote:
Well, I doubt if he'll ever do that, but we could stop bothering him anyway. You'd be amazed at howIf you would just be honest about the fact that you're not working on the halting problem, people
would stop bothering
you.
much time you save. :-)
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()
{
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.
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.
There are more steps, I don't want to overwhelm you.
Yes. For some incorrect reason the programmer of HHH assumes that the
simulation of HHH does not halt, when he knows that HHH does halt.
He does not see that these to assumptions contradict each other.
Your logic includes a statement the equivalent of "If we assume
that 1 is equal to 2".
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()
{
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.
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.
On 6/9/2025 5:26 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 06:04 schreef olcott:
On 6/8/2025 10:54 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
On 6/8/2025 10:31 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
void DDD()Do not imply that I support your claims.
{
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*
I am not implying anything. I am directly stating
that you have agreed that when DDD is correctly simulated
by HHH that it cannot possibly reach its own simulated
"return" instruction and terminate normally.
Endless recursion is endless recursion. Correctly simulated endless
recursion is endless recursion.
Great. No one else besides you and I agree that DDD
correctly simulated by HHH cannot possibly reach its
*simulated "return" instruction final halt state*
Nobody denied it. You are fighting windmills.
We all agree that your HHH fails to reach the end of the simulation of
the input. An input that specifies a halting program, but HHH cannot
simulate it.
This has no useful or interesting
consequences. Do you agree?
It is very useful because it is isomorphic to this:
(The standard Halting Problem counter-example input)
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Indeed, it shows that simulation is not the right way to try to refute
the proof of the halting theorem, because a simulator will never be
able to simulate itself correctly up to the end.
It is ridiculously stupid to require a non-terminating
input to be simulated up to its non-existent end.
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()
{
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.
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?
_DDD()
[00002192] 55 push ebp
[00002193] 8bec mov ebp,esp
[00002195] 6892210000 push 00002192
[0000219a] e833f4ffff call 000015d2 // call HHH
[0000219f] 83c404 add esp,+04
[000021a2] 5d pop ebp
[000021a3] c3 ret
How the f-ck does DDD correctly emulated by HHH
reach its own "ret" instruction final halt state?
That you have dodged this question hundreds of times
proves that you are a liar.
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()
{
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.
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?
On 6/9/2025 10:06 AM, dbush wrote:
On 6/9/2025 10:55 AM, olcott wrote:
On 6/9/2025 6:55 AM, dbush wrote:
On 6/9/2025 12:15 AM, olcott wrote:
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()
{
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.
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
Which you stated only includes the instructions of the function DDD on >>>> multiple occasions (see below),
It is proven that you are a liar by the part of
my reply that you erased.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.
Then you admit that that finite string includes the machine code of the
function DDD, the machine code of the function HHH, and the machine
code of everything that HHH calls down to the OS level, and that
address 000015c3 is part of DDD?
I admit that:
(a) DDD correctly simulated by HHH,
(b) the directly executed DDD() and
(c) the directly executed HHH()
WOULD NEVER STOP RUNNING UNLESS
HHH ABORTS ITS SIMULATION OF DDD.
On 6/9/2025 11:12 AM, dbush wrote:
On 6/9/2025 12:06 PM, olcott wrote:
On 6/9/2025 10:54 AM, dbush wrote:
On 6/9/2025 11:49 AM, olcott wrote:
On 6/9/2025 10:34 AM, dbush wrote:
On 6/9/2025 11:29 AM, olcott wrote:
On 6/9/2025 10:06 AM, dbush wrote:
On 6/9/2025 10:55 AM, olcott wrote:
On 6/9/2025 6:55 AM, dbush wrote:
On 6/9/2025 12:15 AM, olcott wrote:
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
Which you stated only includes the instructions of the function DDD on
multiple occasions (see below),
It is proven that you are a liar by the part of
my reply that you erased.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.
Then you admit that that finite string includes the machine code of the
function DDD, the machine code of the function HHH, and the machine >>>>>>>> code of everything that HHH calls down to the OS level, and that >>>>>>>> address 000015c3 is part of DDD?
I admit that:
(a) DDD correctly simulated by HHH,
(b) the directly executed DDD() and
(c) the directly executed HHH()
WOULD NEVER STOP RUNNING UNLESS
HHH ABORTS ITS SIMULATION OF DDD.
Because this is true it derives conclusive proof
that the input to HHH(DDD) specifies a non-halting
sequence of configurations.
That people here disagree with self-evident truth
seems to indicate that people here are liars.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
In other words, a non-answer. I'll take that as a no.
And since your HHH doesn't work with algorithms (or their description / >>>>>> specification) as you've admitted, you're not working on the halting >>>>>> problem.
You are far too sloppy in your interpretation of the
meaning of words. Also when I do provide an answer
you simply ignore it.
Replying with something other than "yes" or "no" to a yes or no
question is not an answer.
By replying to a yes or no question with the full
and complete justification forces the respondent
to look more deeply into these things than simply
dismissing a view out-of-hand without review.
But by not including the yes or no you dishonestly dodge the question.
Not at all. Not in the least little bit. By forcing my
reviewers to point out an error in my actual reasoning
I prove who is the actual ignorant one.
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.
On 6/9/2025 2:56 AM, Mikko wrote:
On 2025-06-09 02:50:59 +0000, olcott said:
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*
Being called a "liar" by a liar does not damn.
As is clear from the above C code, DDD() specifies what HHH specifies
for the case it is called with DDD as the only argument. In particular,
if HHH specifies a recursive for that case then so does DDD. And if
HHH specifies a recursive simulation that can never reach its final
halt state then so does DDD. And if HHH specifies a non-halting
behaviour so does DDD. Etc.
That is not quite the way that it actually works.
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
If simulating halt decider H correctly simulates its
input D until H correctly determines that its simulated D
would never stop running unless aborted then
H can abort its simulation of D and correctly report that D
specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
DDD emulated by HHH, the directly executed DDD()
and the directly executed HHH() would never stop
running unless HHH aborts its simulation of DDD.
*According to the above criteria that means*
When DDD does abort its simulation of DDD then
HHH correctly reports that its input specifies
a non-halting sequence of configurations.
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.
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:
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.
I switched to the term: "termination analyzer" because halt deciders
have the impossible task of being all knowing. Most people are confused
by the term "partial halt decider". HHH is a termination analyzer that correctly rejects the HP counter-example input as non-halting.
If HHH is a deider it returns. The first insturunction
after the return terminates the execution of DDD.
That is not exactly the way it works. See line 964 https://github.com/plolcott/x86utm/blob/master/Halt7.c
On 6/10/2025 1:55 AM, Richard Heathfield wrote:
On 10/06/2025 01:26, Richard Damon wrote:
<snip>
Your logic includes a statement the equivalent of "If we assume that
1 is equal to 2".
For low values of 2, presumably.
I count that as the reckless disregard for the truth
that loses defamation cases. I made no actual mistakes.
If you are going to claim that I did then you must be
specific or I cannot correct your error. Claiming that
I did make a mistake when there is no evidence this
is defamation.
On 6/10/2025 6:46 AM, Mikko wrote:
On 2025-06-09 15:29:26 +0000, olcott said:
On 6/9/2025 10:06 AM, dbush wrote:
On 6/9/2025 10:55 AM, olcott wrote:
On 6/9/2025 6:55 AM, dbush wrote:
On 6/9/2025 12:15 AM, olcott wrote:
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
Which you stated only includes the instructions of the function
DDD on multiple occasions (see below),
It is proven that you are a liar by the part of
my reply that you erased.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.
Then you admit that that finite string includes the machine code of
the function DDD, the machine code of the function HHH, and the
machine code of everything that HHH calls down to the OS level, and
that address 000015c3 is part of DDD?
I admit that:
(a) DDD correctly simulated by HHH,
(b) the directly executed DDD() and
(c) the directly executed HHH()
WOULD NEVER STOP RUNNING UNLESS
HHH ABORTS ITS SIMULATION OF DDD.
However, because HHH aborts its simulation,
(c) the directly executed HHH(DDD) halts, and therefore
(b) the directly executed DDD() halts, and therefore
(a) the correctly simulated DDD halts.
The correctly simulated DDD cannot possibly halt
when you understand that it must reach its own
simulated "return" statement final halt state.
This means that the input to HHH(DDD) does specify
a non-halting sequence of configurations. Anyone
looking at this any other way was simply wrong.
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.
Unless you are very good at software engineering you
won't be able to begin to understand all of the
non-halting behavior patterns. Mike used the simplest
one: infinite loop.
On 6/10/2025 6:52 AM, Mikko wrote:
On 2025-06-09 16:24:58 +0000, olcott said:
On 6/9/2025 11:12 AM, dbush wrote:
On 6/9/2025 12:06 PM, olcott wrote:
On 6/9/2025 10:54 AM, dbush wrote:
On 6/9/2025 11:49 AM, olcott wrote:
On 6/9/2025 10:34 AM, dbush wrote:
On 6/9/2025 11:29 AM, olcott wrote:
On 6/9/2025 10:06 AM, dbush wrote:
On 6/9/2025 10:55 AM, olcott wrote:
On 6/9/2025 6:55 AM, dbush wrote:
On 6/9/2025 12:15 AM, olcott wrote:
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: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
Which you stated only includes the instructions of the >>>>>>>>>>>> function DDD on multiple occasions (see below),
It is proven that you are a liar by the part of
my reply that you erased.
HHH(DDD) takes a finite string of x86 instructions
that specify that HHH simulates itself simulating DDD.
Then you admit that that finite string includes the machine >>>>>>>>>> code of the function DDD, the machine code of the function >>>>>>>>>> HHH, and the machine code of everything that HHH calls down to >>>>>>>>>> the OS level, and that address 000015c3 is part of DDD?
I admit that:
(a) DDD correctly simulated by HHH,
(b) the directly executed DDD() and
(c) the directly executed HHH()
WOULD NEVER STOP RUNNING UNLESS
HHH ABORTS ITS SIMULATION OF DDD.
Because this is true it derives conclusive proof
that the input to HHH(DDD) specifies a non-halting
sequence of configurations.
That people here disagree with self-evident truth
seems to indicate that people here are liars.
In epistemology (theory of knowledge), a self-evident
proposition is a proposition that is known to be true
by understanding its meaning without proof...
https://en.wikipedia.org/wiki/Self-evidence
In other words, a non-answer. I'll take that as a no.
And since your HHH doesn't work with algorithms (or their
description / specification) as you've admitted, you're not
working on the halting problem.
You are far too sloppy in your interpretation of the
meaning of words. Also when I do provide an answer
you simply ignore it.
Replying with something other than "yes" or "no" to a yes or no
question is not an answer.
By replying to a yes or no question with the full
and complete justification forces the respondent
to look more deeply into these things than simply
dismissing a view out-of-hand without review.
But by not including the yes or no you dishonestly dodge the question. >>>>
Not at all. Not in the least little bit. By forcing my
reviewers to point out an error in my actual reasoning
I prove who is the actual ignorant one.
No, you don't. You only force them to point out an error in your
actual reasoning, which they have aleady done. They have also
proven that the actual ingnorant one you.
No reviewer has ever pointed out any error in my actual
reasoning. Most attempts to point to any error changed
the words that I said and then rebutted these changed words.
I point out Richard's errors hundreds of times and he never
hears a single word of my corrections.
It seems that some of my reviewers simply don't know enough
about computer science or C programming. They don't know
that they don't know enough, so ignorance squared.
On 6/10/2025 6:24 AM, Richard Damon wrote:
On 6/9/25 8:47 PM, olcott wrote:
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?
Who said correctly simulated by HHH?
You need to make a decision on which part of your arguement is a lie?
Is HHH a program? if not, your whole argument is a category error.
(you have actually admitted this error)
In other words you are stupidly making the counter-factual
statement that termination analyzers cannot operate on C
functions. It is a verified fact that they do operate
on C functions so shut-the-f_ck-up about this.
On 6/10/2025 4:00 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:43 schreef olcott:
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:
And because your HHH does not work with the description/HHH(DDD) takes a finite string of x86 instructions that specify that >>>>> HHH simulates itself simulating DDD.
specification of an algorithm, by your own admission, you're not
working on the halting problem.
And HHH fails to see the specification of the x86 instructions. ItIt is a verified fact that unless the outer HHH aborts its simulation
aborts before it can see how the program ends.
of DDD that DDD simulated by HHH the directly executed DDD() and the
directly executed HHH() would never stop running.
But the abort is coded in the input.
I corrected you on this too many times. Stopping running is not halting.
Only reaching a final halt state is halting.
That I had to tell you this several times seems to prove that you are dishonest.
On 6/10/2025 2:32 PM, joes wrote:
Am Tue, 10 Jun 2025 12:27:48 -0500 schrieb olcott:
On 6/10/2025 4:00 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:43 schreef olcott:
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:
And because your HHH does not work with the description/HHH(DDD) takes a finite string of x86 instructions that specify that >>>>>>> HHH simulates itself simulating DDD.
specification of an algorithm, by your own admission, you're not >>>>>>>> working on the halting problem.
DDD does not specify that HHH should simulate itself. It could be
simulated by HHH1, which would (as you point out) not simulate itself.
And HHH fails to see the specification of the x86 instructions. It >>>>>> aborts before it can see how the program ends.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.
But the abort is coded in the input.
I corrected you on this too many times. Stopping running is not halting. >>> Only reaching a final halt state is halting.
That I had to tell you this several times seems to prove that you are
dishonest.
No, the *input* DDD calls HHH, which contains an abort, but the outer
HHH doesn't simulate it up to that point.
Infinite_Loop()
{
HERE: goto HERE;
return;
}
Likewise Infinite_Loop() is never simulated to
completion BECAUSE THERE IS NO COMPLETION.
On 6/10/2025 6:59 AM, Mikko wrote:
On 2025-06-09 14:38:02 +0000, olcott said:
On 6/9/2025 2:56 AM, Mikko wrote:
On 2025-06-09 02:50:59 +0000, olcott said:
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*
Being called a "liar" by a liar does not damn.
As is clear from the above C code, DDD() specifies what HHH specifies
for the case it is called with DDD as the only argument. In particular, >>>> if HHH specifies a recursive for that case then so does DDD. And if
HHH specifies a recursive simulation that can never reach its final
halt state then so does DDD. And if HHH specifies a non-halting
behaviour so does DDD. Etc.
That is not quite the way that it actually works.
Yes it is. If it were not you would have pointed where there is an
error.
I only point out the first error and the skip the rest of the post.
I usually have to point out the same error dozens of times before
anyone notices that I said anything at all. That is why I skip the
rest of the post after the first error.
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.
Unless you are very good at software engineering
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:
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.
I switched to the term: "termination analyzer" because halt deciders
have the impossible task of being all knowing.
Most people are confused by the term "partial halt decider".
On 6/10/2025 4:00 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:43 schreef olcott:
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()
{
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.
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.
But the abort is coded in the input.
I corrected you on this too many times. Stopping running
is not halting. Only reaching a final halt state is halting.
That I had to tell you this several times seems to prove
that you are dishonest.
On 6/10/2025 3:49 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:39 schreef olcott:
On 6/9/2025 5:26 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 06:04 schreef olcott:
On 6/8/2025 10:54 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
On 6/8/2025 10:31 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
void DDD()Do not imply that I support your claims.
{
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*
I am not implying anything. I am directly stating
that you have agreed that when DDD is correctly simulated
by HHH that it cannot possibly reach its own simulated
"return" instruction and terminate normally.
Endless recursion is endless recursion. Correctly simulated endless >>>>>> recursion is endless recursion.
Great. No one else besides you and I agree that DDD
correctly simulated by HHH cannot possibly reach its
*simulated "return" instruction final halt state*
Nobody denied it. You are fighting windmills.
We all agree that your HHH fails to reach the end of the simulation
of the input. An input that specifies a halting program, but HHH
cannot simulate it.
This has no useful or interesting
consequences. Do you agree?
It is very useful because it is isomorphic to this:
(The standard Halting Problem counter-example input)
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Indeed, it shows that simulation is not the right way to try to
refute the proof of the halting theorem, because a simulator will
never be able to simulate itself correctly up to the end.
It is ridiculously stupid to require a non-terminating
input to be simulated up to its non-existent end.
It is even more stupid to ignore the halting part of the input (with a
premature abort) and claim it is not halting.
It waiting forever is not long enough (and it is)
then your idea about "premature abort" is incorrect.
That you do not understand that unless the outermost
HHH aborts that no HHH ever aborts is your mistake
not mine.
On 6/11/2025 7:38 AM, Fred. Zwarts wrote:That is the interesting part to me. Can somebody formalise or generalise
Op 10.jun.2025 om 19:25 schreef olcott:
On 6/10/2025 3:49 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:39 schreef olcott:
On 6/9/2025 5:26 AM, Fred. Zwarts wrote:
Indeed, it shows that simulation is not the right way to try to
refute the proof of the halting theorem, because a simulator will
never be able to simulate itself correctly up to the end.
So you aren't bright enough to understand that infinite recursion doesIt is ridiculously stupid to require a non-terminating input to beIt is even more stupid to ignore the halting part of the input (with
simulated up to its non-existent end.
a premature abort) and claim it is not halting.
It waiting forever is not long enough (and it is) then your idea about
"premature abort" is incorrect.
Running one more cycle is enough to see the simulated abort (unless you
change the input to another input specifying another program that needs
again another cycle. That other input is only in your dream. The input
specified in Halt7.c is the input we discuss.
not halt on its own.
HHH waits until it sees that its input calls the same function with the
same parameters twice in sequence with no conditional branch inbetween
the beginning of DDD and its call to HHH(DDD). It does not matter that
there are conditional branch instructions in HHH because they cannot be reached and none of them could possibly enable DDD simulated by HHH to
reach its own "return" statement final halt state.
I have told you this many times and you just aren't bright enough to understand. That you are ignorant DOES NOT MAKE ME INCORRECT, IT MAKESIt makes you bad at explaining.
YOU INCORRECT.
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:
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its *simulated >>>>>>> "return" instruction final halt state*
So, you think a partial simulation defines behavior?
Where do you get that LIE from?
It only takes two simulations of DDD by HHH for HHH to correctlyI 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.
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.
On 6/11/2025 9:42 AM, joes wrote:Not when simulated.
Am Wed, 11 Jun 2025 09:11:32 -0500 schrieb olcott:
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:
The fact that HHH reaches its own "return" statement final halt stateIt only takes two simulations of DDD by HHH for HHH to correctlyI 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.
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.
It is also proof that HHH doesn't terminate.
proves that you are 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:
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.
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
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.
A halt decider would be required to determine if a
proof of the Goldbach conjecture halts not knowing
whether this proof is infinite or not.
In addition the concept "analyzer" is essentially different
from "decider". A decider is expected to answer "yes" or "no". A
partial decider is permitted to answer neither and instead to run
forever or to answer "cannot determine". An analyzer is expected to
provide useful information to the developers so that the can change
the program so that it can be trusted to have the required property.
Most people are confused by the term "partial halt decider".
I have seen evdence of that particular confusion.
Most people don't know that a halt decider must be all knowing.
On 6/11/2025 7:43 AM, Fred. Zwarts wrote:
Op 10.jun.2025 om 19:27 schreef olcott:
On 6/10/2025 4:00 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:43 schreef olcott:
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.
But the abort is coded in the input.
I corrected you on this too many times. Stopping running
is not halting. Only reaching a final halt state is halting.
That I had to tell you this several times seems to prove
that you are dishonest.
You have been corrected on this many timed by many people.
Failing to reach the final state because of a premature abort
There is no premature abort you are just stupid.
is no counter argument.
It cannot be, because the verified fact is that the input specifies a
halting program, but your HHH fails to see that part of the input by
the premature abort.
If you are not dishonest or stubborn, you must have a mental problem
to learn from your errors.
On 6/11/2025 7:38 AM, Fred. Zwarts wrote:
Op 10.jun.2025 om 19:25 schreef olcott:
On 6/10/2025 3:49 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:39 schreef olcott:
On 6/9/2025 5:26 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 06:04 schreef olcott:
On 6/8/2025 10:54 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
On 6/8/2025 10:31 PM, Keith Thompson wrote:
olcott <[email protected]> writes:
void DDD()Do not imply that I support your claims.
{
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*
I am not implying anything. I am directly stating
that you have agreed that when DDD is correctly simulated
by HHH that it cannot possibly reach its own simulated
"return" instruction and terminate normally.
Endless recursion is endless recursion. Correctly simulated
endless
recursion is endless recursion.
Great. No one else besides you and I agree that DDD
correctly simulated by HHH cannot possibly reach its
*simulated "return" instruction final halt state*
Nobody denied it. You are fighting windmills.
We all agree that your HHH fails to reach the end of the
simulation of the input. An input that specifies a halting
program, but HHH cannot simulate it.
This has no useful or interesting
consequences. Do you agree?
It is very useful because it is isomorphic to this:
(The standard Halting Problem counter-example input)
int DD()
{
int Halt_Status = HHH(DD);
if (Halt_Status)
HERE: goto HERE;
return Halt_Status;
}
Indeed, it shows that simulation is not the right way to try to
refute the proof of the halting theorem, because a simulator will
never be able to simulate itself correctly up to the end.
It is ridiculously stupid to require a non-terminating
input to be simulated up to its non-existent end.
It is even more stupid to ignore the halting part of the input (with
a premature abort) and claim it is not halting.
It waiting forever is not long enough (and it is)
then your idea about "premature abort" is incorrect.
Running one more cycle is enough to see the simulated abort (unless
you change the input to another input specifying another program that
needs again another cycle. That other input is only in your dream. The
input specified in Halt7.c is the input we discuss.
So you aren't bright enough to understand that
infinite recursion does not halt on its own.
HHH waits until it sees that its input calls the same
function with the same parameters twice in sequence
with no conditional branch inbetween the beginning
of DDD and its call to HHH(DDD). It does not matter
that there are conditional branch instructions in HHH
because they cannot be reached and none of them could
possibly enable DDD simulated by HHH to reach its own
"return" statement final halt state.
The outermost HHH sees this infinite recursion behavior
pattern one whole recursive emulation before the next
inner one. Because each instance of HHH has the same
machine code unless the outmost one aborts none of them
abort. If the outermost HHH waits on the inner one then
they all wait and the abort never occurs.
Unless HHH(DDD) aborts the simulation of its input
DDD simulated by HHH, the directly executed DDD() and
the directly executed HHH() NEVER STOP RUNNING.
I have told you this many times and you just aren't
bright enough to understand. That you are ignorant
DOES NOT MAKE ME INCORRECT, IT MAKES YOU INCORRECT.
That you do not understand that unless the outermost
HHH aborts that no HHH ever aborts is your mistake
not mine.
That you do not see that one more cycle is enough, because you keep
changing the input to something you dream about but is not the actual
input is your problem, not mine.
On 6/11/2025 10:04 AM, joes wrote:
Am Wed, 11 Jun 2025 09:59:46 -0500 schrieb olcott:
On 6/11/2025 9:42 AM, joes wrote:Not when simulated.
Am Wed, 11 Jun 2025 09:11:32 -0500 schrieb olcott:
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:
The fact that HHH reaches its own "return" statement final halt stateIt only takes two simulations of DDD by HHH for HHH to correctly >>>>>>> recognize a non-halting behavior pattern.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.
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.
It is also proof that HHH doesn't terminate.
proves that you are incorrect.
DDD correctly simulated by HHH proves beyond all
possible doubt the exact behavior that the input
to HHH(DDD) specifies.
On 6/12/2025 4:51 AM, Fred. Zwarts wrote:
Op 11.jun.2025 om 17:34 schreef olcott:*Counter-factual and apparently over-your-head*
On 6/11/2025 10:04 AM, joes wrote:
Am Wed, 11 Jun 2025 09:59:46 -0500 schrieb olcott:
On 6/11/2025 9:42 AM, joes wrote:Not when simulated.
Am Wed, 11 Jun 2025 09:11:32 -0500 schrieb olcott:
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:
The fact that HHH reaches its own "return" statement final halt state >>>>> proves that you are incorrect.It only takes two simulations of DDD by HHH for HHH to correctly >>>>>>>>> recognize a non-halting behavior pattern.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. >>>>>>>>>>
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.
It is also proof that HHH doesn't terminate.
DDD correctly simulated by HHH proves beyond all
possible doubt the exact behavior that the input
to HHH(DDD) specifies.
No. hHH aborts prematurely.
When HHH aborts after it emulates N instructions of DDD,
this same correctly emulated DDD has never reached its
own "return" statement final halt state.
On 6/12/2025 4:51 AM, Fred. Zwarts wrote:
Op 11.jun.2025 om 17:34 schreef olcott:*Counter-factual and apparently over-your-head*
On 6/11/2025 10:04 AM, joes wrote:
Am Wed, 11 Jun 2025 09:59:46 -0500 schrieb olcott:
On 6/11/2025 9:42 AM, joes wrote:Not when simulated.
Am Wed, 11 Jun 2025 09:11:32 -0500 schrieb olcott:
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:
The fact that HHH reaches its own "return" statement final halt state >>>>> proves that you are incorrect.It only takes two simulations of DDD by HHH for HHH to correctly >>>>>>>>> recognize a non-halting behavior pattern.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. >>>>>>>>>>
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.
It is also proof that HHH doesn't terminate.
DDD correctly simulated by HHH proves beyond all
possible doubt the exact behavior that the input
to HHH(DDD) specifies.
No. hHH aborts prematurely.
When HHH aborts after it emulates N instructions of DDD,
this same correctly emulated DDD has never reached its
own "return" statement final halt state.
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:
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.
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
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.
Most people don't know that a halt decider must be all knowing.
On 6/11/2025 9:34 AM, joes wrote:
Am Wed, 11 Jun 2025 08:55:37 -0500 schrieb olcott:
On 6/11/2025 7:38 AM, Fred. Zwarts wrote:That is the interesting part to me. Can somebody formalise or generalise
Op 10.jun.2025 om 19:25 schreef olcott:
On 6/10/2025 3:49 AM, Fred. Zwarts wrote:
Op 09.jun.2025 om 16:39 schreef olcott:
On 6/9/2025 5:26 AM, Fred. Zwarts wrote:
Indeed, it shows that simulation is not the right way to try to >>>>>>>> refute the proof of the halting theorem, because a simulator will >>>>>>>> never be able to simulate itself correctly up to the end.
this statement?
So you aren't bright enough to understand that infinite recursion doesIt is ridiculously stupid to require a non-terminating input to be >>>>>>> simulated up to its non-existent end.It is even more stupid to ignore the halting part of the input (with >>>>>> a premature abort) and claim it is not halting.
It waiting forever is not long enough (and it is) then your idea about >>>>> "premature abort" is incorrect.
Running one more cycle is enough to see the simulated abort (unless you >>>> change the input to another input specifying another program that needs >>>> again another cycle. That other input is only in your dream. The input >>>> specified in Halt7.c is the input we discuss.
not halt on its own.
HHH waits until it sees that its input calls the same function with the
same parameters twice in sequence with no conditional branch inbetween
the beginning of DDD and its call to HHH(DDD). It does not matter that
there are conditional branch instructions in HHH because they cannot be
reached and none of them could possibly enable DDD simulated by HHH to
reach its own "return" statement final halt state.
What does HHH(HHH) return?
I have told you this many times and you just aren't bright enough toIt makes you bad at explaining.
understand. That you are ignorant DOES NOT MAKE ME INCORRECT, IT MAKES
YOU INCORRECT.
I may be bad at explaining, that does not make me incorrect.
On 6/11/2025 3:23 AM, Mikko wrote:
On 2025-06-10 16:07:56 +0000, olcott said:
On 6/10/2025 6:59 AM, Mikko wrote:
On 2025-06-09 14:38:02 +0000, olcott said:
On 6/9/2025 2:56 AM, Mikko wrote:
On 2025-06-09 02:50:59 +0000, olcott said:
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*
Being called a "liar" by a liar does not damn.
As is clear from the above C code, DDD() specifies what HHH specifies >>>>>> for the case it is called with DDD as the only argument. In particular, >>>>>> if HHH specifies a recursive for that case then so does DDD. And if >>>>>> HHH specifies a recursive simulation that can never reach its final >>>>>> halt state then so does DDD. And if HHH specifies a non-halting
behaviour so does DDD. Etc.
That is not quite the way that it actually works.
Yes it is. If it were not you would have pointed where there is an
error.
I only point out the first error and the skip the rest of the post.
I usually have to point out the same error dozens of times before
anyone notices that I said anything at all. That is why I skip the
rest of the post after the first error.
You did neither when you claimed "That is not quite the way that it
actually works".
That you erased that part and then said that
I never said anything is dishonest.
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.
On 6/11/2025 9:42 AM, joes wrote:
Am Wed, 11 Jun 2025 09:11:32 -0500 schrieb olcott:
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:
The *input* to simulating termination analyzer HHH(DDD)
specifies recursive simulation that can never reach its *simulated >>>>>>>>> "return" instruction final halt state*
So, you think a partial simulation defines behavior?
Where do you get that LIE from?
That is what HHH does.
It only takes two simulations of DDD by HHH for HHH to correctlyI 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.
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.
It is also proof that HHH doesn't terminate.
The fact that HHH reaches its own "return" statement
final halt state proves that you are incorrect.
On 6/13/2025 4:16 AM, Fred. Zwarts wrote:
Op 12.jun.2025 om 17:54 schreef olcott:
On 6/12/2025 4:51 AM, Fred. Zwarts wrote:
Op 11.jun.2025 om 17:34 schreef olcott:*Counter-factual and apparently over-your-head*
On 6/11/2025 10:04 AM, joes wrote:
Am Wed, 11 Jun 2025 09:59:46 -0500 schrieb olcott:
On 6/11/2025 9:42 AM, joes wrote:Not when simulated.
Am Wed, 11 Jun 2025 09:11:32 -0500 schrieb olcott:
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:
The fact that HHH reaches its own "return" statement final haltIt only takes two simulations of DDD by HHH for HHH to correctly >>>>>>>>>>> recognize a non-halting behavior pattern.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. >>>>>>>>>>>>
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.
It is also proof that HHH doesn't terminate.
state
proves that you are incorrect.
DDD correctly simulated by HHH proves beyond all
possible doubt the exact behavior that the input
to HHH(DDD) specifies.
No. hHH aborts prematurely.
When HHH aborts after it emulates N instructions of DDD,
this same correctly emulated DDD has never reached its
own "return" statement final halt state.
Wrong. The input for HHH is a pointer to code, including the part
specifying the abort and halt.
World-class simulators show that more then N instructions must be
simulated, including those within HHH. That HHH simulates only N
instructions means that the abort is premature.
It is ridiculously stupid to require a simulating termination
analyzer to simulating a non terminating input to its non-existent
end.
That HHH never reaches the end of its simulation is a failure of HHH,
not a property specified in the input.
Then show ALL of the details of exactly how DDD correctly
simulated by HHH reaches its simulated "return" statement
final halt state.
It is like you are claiming that square circles exist and
refuse to draw one.
void DDD()
{
HHH(DDD);
return;
}
The input to HHH(DDD) specifies non-halting behavior in
that DDD correctly simulated by HHH cannot possibly reach
its own simulated "return" statement final halt state.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 10:33:27 |
| Calls: | 12,100 |
| Files: | 15,003 |
| Messages: | 6,517,989 |