XPost: comp.theory, sci.logic

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:

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?

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.

(b) Within the theory of computation HHH is not allowed to report
    on the behavior of its caller.

No, it should report on the behaviour of the program specified in the
input, even if the caller uses the same code.

(c) HHH(DDD) does correctly report on the behavior that its
    input specifies.

It does not. It seems you still does not understand the verified fact
that the input is a pointer to a program including DDD and all the
functions it uses, including the code that aborts and halts.
That HHH has a bug that makes that it does not see that part of the specification does not change the specification of a halting program.
It is not the HHH in your dream that does not abort.
Sum(2,3) should report the sum of 2 and 3, not the sum of 7 and 9, even
if you dream about 7 and 9.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

Op 14.jun.2025 om 16:17 schreef olcott:

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.

Indeed, even a beginner will see that HHH fails to reach the end of the simulation of a halting program.

It is also required that one know that in computer science
halting means reaching a final halt state.

But preventing a program to halt (e.g. by turning off a computer, or
aborting a simulation) does not make a program non-halting.

If you have less technical competence than this then the
problem is your lack of technical competence.

So, why do you continue if you do not even understand this?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

On 6/15/25 9:57 AM, olcott wrote:

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:

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?

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.

But if the input specifies the program that called it, it must report on
that, and thus you claim is just another self-contradiction.

Sorry, your "logic" system is just fundamentally broken.

(b) Within the theory of computation HHH is not allowed to report
     on the behavior of its caller.

No, it should report on the behaviour of the program specified in the
input, even if the caller uses the same code.

(c) HHH(DDD) does correctly report on the behavior that its
     input specifies.

It does not.

You cannot show the detailed steps that "it does not" because
you are wrong. You simply don't understand these things.

No, YOU ARE.

When you take a guess and provide zero supporting reasoning
for this guess it does not count as any actual rebuttal at all.

The answer HAS been provided, many times, and is clearly overy your head.

It has even been done by your own words, when put into the actual
meaning they have.

You have admitted that D() (and thus DDD() ) will halt when run, and
thus is can NOT be the correct answer for HHH(DDD) to say it won't.

You are just too stupid to understand the facts that you yourself verify,

Sorry, you are just proving your mental state.

It seems you still does not understand the verified fact that the
input is a pointer to a program including DDD and all the functions it
uses, including the code that aborts and halts.
That HHH has a bug that makes that it does not see that part of the
specification does not change the specification of a halting program.
It is not the HHH in your dream that does not abort.
Sum(2,3) should report the sum of 2 and 3, not the sum of 7 and 9,
even if you dream about 7 and 9.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

Op 15.jun.2025 om 16:01 schreef olcott:

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:

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?

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.

(b) Within the theory of computation HHH is not allowed to report
     on the behavior of its caller.

No, it should report on the behaviour of the program specified in the
input, even if the caller uses the same code.

(c) HHH(DDD) does correctly report on the behavior that its
     input specifies.

It does not. It seems you still does not understand the verified fact
that the input is a pointer to a program including DDD and all the
functions it uses, including the code that aborts and halts.

That HHH has a bug that makes that it does not see that part of the
specification does not change the specification of a halting program.

You cannot possibly show any bug because you are wrong.
That DDD correctly simulated by HHH cannot reach its own
final halt state does not show that HHH has a bug. It
does show that you don't even understand what a bug is.

The bug has been shown to you many times. That you do not understand
your own errors does not change the fact that the bug is there. The bug
is that HHH does not count the conditional branch instructions when it
is simulating itself. Therefore, the program performs an unneeded abort
for a finite recursion.

Dreaming of a program without bugs and ignoring all proposed corrections
does not make your program bug free.

That you keep dreaming does not make me wrong.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: comp.theory, sci.logic

Op 15.jun.2025 om 15:57 schreef olcott:

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:

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?

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.

So, you do not understand that the behaviour of the caller is
irrelevant. The decider must report on the behaviour of its input, even
if this input has exactly the same behaviour as the caller.

(b) Within the theory of computation HHH is not allowed to report
     on the behavior of its caller.

No, it should report on the behaviour of the program specified in the
input, even if the caller uses the same code.

(c) HHH(DDD) does correctly report on the behavior that its
     input specifies.

It does not.

You cannot show the detailed steps that "it does not" because
you are wrong. You simply don't understand these things.

I did that several times, but apparently you do not understand it.

When you take a guess and provide zero supporting reasoning
for this guess it does not count as any actual rebuttal at all.

My rebuttal is the verified fact that the input for HHH is a pointer to
code that includes the code to abort and halt.
You ignore that and keep dreaming of an infinite recursion
Your HHH aborts a finite recursion, makes a wild guess and you keep
dreaming that it is correct.
A dream is not a rebuttal.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)