On 8/6/25 8:11 AM, olcott wrote:

On 8/6/2025 6:33 AM, Richard Damon wrote:

On 8/6/25 7:20 AM, olcott wrote:

On 8/6/2025 2:09 AM, Mikko wrote:

On 2025-08-05 15:17:53 +0000, olcott said:

On 8/5/2025 2:14 AM, Mikko wrote:

On 2025-08-04 21:55:28 +0000, olcott said:

Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern: abort simulation >>>>>>> and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Can you see that DD correctly simulated by HHH demonstrates the
recursive simulation non halting behavior pattern that cannot
possibly reach its own "if" statement?

No, we can't hallucinate that. HHH does not demostrate. It simply
reports
incorrectly.

*This process is known as cooperative multi-tasking*

Irrelevant. What matters is that a recursion is not a non-halting
pattern.

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

Proof of universals by example is just a fallacy.

For example, there is a recusion in 5! = 5 * (4!) and more generally in >>>> (n + 1)! = (n + 1) * n! but there is non-halting pattern there.

Likewise there is a recursive simulation in HHH(DD) but no non-halting >>>> pattern.

Then you must know how DDD correctly emulated
by HHH reaches its own emulated final state.

No, the problem is that your HHH just doesn't correctly emulates its
input and you are proving you are just a stupid pathological liar.

You cannot possibly show that any step of DDD emulated
by HHH according to the definition of the x86 language
is incorrect because these steps are proven correct by
the definition of the x86 language.

Your last step when you abort.

You cannot show the detailed steps of why the infinite
behavior of DDD cannot be accurately predicted by a
finite sample of this behavior.

But the behavior of this input ISN'T infinite.

It is a DIFFERENT input that has the infinite behavior, as that is the
input that includes the code of the HHH that doesn't abort.

You can't find a pattern that shows infinite behavior in an input that
halts.

Your problem is your argument begins with a category error, that you
assume you can make you HHH and DDD not be programs by mis-defining them.

But once you show what you mean for them to do, the proper defintions of
them become clear, and that is that the code of HHH that you try to
ignore as outside of DDD, becomes part of DDD and the input, or HHH
can't do what you claim it does, and all you have done is proven that
you lied about what DDD and HHH actually are.

Sorry, you are just proving that you are just an ignorant liar.

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

On 2025-08-06 11:20:04 +0000, olcott said:

On 8/6/2025 2:09 AM, Mikko wrote:

On 2025-08-05 15:17:53 +0000, olcott said:

On 8/5/2025 2:14 AM, Mikko wrote:

On 2025-08-04 21:55:28 +0000, olcott said:

Simulating Termination Analyzer HHH correctly simulates its input until: >>>>> (a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Can you see that DD correctly simulated by HHH demonstrates the
recursive simulation non halting behavior pattern that cannot possibly >>>>> reach its own "if" statement?

No, we can't hallucinate that. HHH does not demostrate. It simply reports >>>> incorrectly.

*This process is known as cooperative multi-tasking*

Irrelevant. What matters is that a recursion is not a non-halting pattern.

void Infinite_Recursion()
{
Infinite_Recursion();
return;
}

For example, there is a recusion in 5! = 5 * (4!) and more generally in
(n + 1)! = (n + 1) * n! but there is non-halting pattern there.

Likewise there is a recursive simulation in HHH(DD) but no non-halting
pattern.

Then you must know how DDD correctly emulated
by HHH reaches its own emulated final state.

The subject line specifies DD, not DDD.

The "correctly emulated by HHH" is irrelevant. It does not matter whether
HHH emulates correctly or partially or incorrectly or not at all. What
matters is whether the answer it gives agrees with the truth about the termination of DD().

--
Mikko

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

On 8/7/25 8:56 AM, olcott wrote:

On 8/7/2025 2:36 AM, Mikko wrote:

On 2025-08-06 11:20:04 +0000, olcott said:

On 8/6/2025 2:09 AM, Mikko wrote:

On 2025-08-05 15:17:53 +0000, olcott said:

On 8/5/2025 2:14 AM, Mikko wrote:

On 2025-08-04 21:55:28 +0000, olcott said:

Simulating Termination Analyzer HHH correctly simulates its input >>>>>>> until:
(a) Detects a non-terminating behavior pattern: abort simulation >>>>>>> and return 0.
(b) Simulated input reaches its simulated "return" statement:
return 1.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Can you see that DD correctly simulated by HHH demonstrates the
recursive simulation non halting behavior pattern that cannot
possibly reach its own "if" statement?

No, we can't hallucinate that. HHH does not demostrate. It simply
reports
incorrectly.

*This process is known as cooperative multi-tasking*

Irrelevant. What matters is that a recursion is not a non-halting
pattern.

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

For example, there is a recusion in 5! = 5 * (4!) and more generally in >>>> (n + 1)! = (n + 1) * n! but there is non-halting pattern there.

Likewise there is a recursive simulation in HHH(DD) but no non-halting >>>> pattern.

Then you must know how DDD correctly emulated
by HHH reaches its own emulated final state.

The subject line specifies DD, not DDD.

The "correctly emulated by HHH" is irrelevant. It does not matter whether
HHH emulates correctly or partially or incorrectly or not at all. What
matters is whether the answer it gives agrees with the truth about the
termination of DD().

The correctly emulated DD specifies the behavior of the input
to HHH(DD) as opposed to and contrast with the behavior of DD().
No termination analyzer reports on non-inputs.

Right, but the correct emulation of DD *WILL* exactly match the behavior
of the directed executed program, since by definition that must be
matches or the input isn't the correct representation of the program.

If you claim they can be different, show how they can differ, after all, "emulation" derives from the idea of UTM, which is DEFINED to exactly
reproduce the behavior of the program described.

So, anything diffferent means either an incorrect emulation, or
representation.

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

On 2025-08-07 12:56:38 +0000, olcott said:

On 8/7/2025 2:36 AM, Mikko wrote:

On 2025-08-06 11:20:04 +0000, olcott said:

On 8/6/2025 2:09 AM, Mikko wrote:

On 2025-08-05 15:17:53 +0000, olcott said:

On 8/5/2025 2:14 AM, Mikko wrote:

On 2025-08-04 21:55:28 +0000, olcott said:

Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1. >>>>>>>
int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Can you see that DD correctly simulated by HHH demonstrates the
recursive simulation non halting behavior pattern that cannot possibly >>>>>>> reach its own "if" statement?

No, we can't hallucinate that. HHH does not demostrate. It simply reports
incorrectly.

*This process is known as cooperative multi-tasking*

Irrelevant. What matters is that a recursion is not a non-halting pattern. >>>

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

For example, there is a recusion in 5! = 5 * (4!) and more generally in >>>> (n + 1)! = (n + 1) * n! but there is non-halting pattern there.

Likewise there is a recursive simulation in HHH(DD) but no non-halting >>>> pattern.

Then you must know how DDD correctly emulated
by HHH reaches its own emulated final state.

The subject line specifies DD, not DDD.

The "correctly emulated by HHH" is irrelevant. It does not matter whether
HHH emulates correctly or partially or incorrectly or not at all. What
matters is whether the answer it gives agrees with the truth about the
termination of DD().

The correctly emulated DD specifies the behavior of the input
to HHH(DD) as opposed to and contrast with the behavior of DD().
No termination analyzer reports on non-inputs.

If the answer returned by HHH(DD) does not agree with the actual
behaviour of DD() then HHH does not meet the requirements of a
halt decider nor even a partial halt decider.

--
Mikko

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

On 08/08/2025 07:59, Mikko wrote:

On 2025-08-07 12:56:38 +0000, olcott said:

<snip>

The correctly emulated DD specifies the behavior of the input
to HHH(DD) as opposed to and contrast with the behavior of DD().
No termination analyzer reports on non-inputs.

If the answer returned by HHH(DD) does not agree with the actual
behaviour of DD() then HHH does not meet the requirements of a
halt decider nor even a partial halt decider.

True enough.

Perhaps more importantly, it's hard to imagine a clearer case of
weasel words. DD is clearly an input to HHH(DD), and to claim
otherwise is just bizarre.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 8/8/25 10:59 AM, olcott wrote:

On 8/8/2025 2:06 AM, Richard Heathfield wrote:

On 08/08/2025 07:59, Mikko wrote:

On 2025-08-07 12:56:38 +0000, olcott said:

<snip>

The correctly emulated DD specifies the behavior of the input
to HHH(DD) as opposed to and contrast with the behavior of DD().
No termination analyzer reports on non-inputs.

If the answer returned by HHH(DD) does not agree with the actual
behaviour of DD() then HHH does not meet the requirements of a
halt decider nor even a partial halt decider.

True enough.

Perhaps more importantly, it's hard to imagine a clearer case of
weasel words. DD is clearly an input to HHH(DD), and to claim
otherwise is just bizarre.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

But it isn't the behavior of a non-input.

It is the defined behavior of the input, which semantically means the
program and its behavior.

You are just saying that semantic meaning doesn't matter.

Correct simulation is a correct measure of this behavior.
Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.
In the case it is the input that rules and non-inputs are
irrelevant.

Right, and correct simulation of this exact input will halt, at least as
long as it IS a correct input of the program specified, which includes
the code of the HHH that you claim gets the right answer and thus aborts.

Anything else is just proof that you are lying.

Sorry, you have sunk your reputation with all the lies you have told,
and then don't even try to answer the errors, but just repeat the lies.

That shows that you understand you can't go more basic, or quote actual sources, because they will show that you are just lying.

Thus, you are just proving that you are just a totally ingnorant and
stupid pathological lying idiot that doesn't care about the truth, or is
so mentally crippled that he can't understand the truth.

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

Op 08.aug.2025 om 17:40 schreef olcott:

On 8/8/2025 1:59 AM, Mikko wrote:

On 2025-08-07 12:56:38 +0000, olcott said:

On 8/7/2025 2:36 AM, Mikko wrote:

On 2025-08-06 11:20:04 +0000, olcott said:

On 8/6/2025 2:09 AM, Mikko wrote:

On 2025-08-05 15:17:53 +0000, olcott said:

On 8/5/2025 2:14 AM, Mikko wrote:

On 2025-08-04 21:55:28 +0000, olcott said:

Simulating Termination Analyzer HHH correctly simulates its
input until:
(a) Detects a non-terminating behavior pattern: abort
simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: >>>>>>>>> return 1.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Can you see that DD correctly simulated by HHH demonstrates the >>>>>>>>> recursive simulation non halting behavior pattern that cannot >>>>>>>>> possibly reach its own "if" statement?

No, we can't hallucinate that. HHH does not demostrate. It
simply reports
incorrectly.

*This process is known as cooperative multi-tasking*

Irrelevant. What matters is that a recursion is not a non-halting
pattern.

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

For example, there is a recusion in 5! = 5 * (4!) and more
generally in
(n + 1)! = (n + 1) * n! but there is non-halting pattern there.

Likewise there is a recursive simulation in HHH(DD) but no non-
halting
pattern.

Then you must know how DDD correctly emulated
by HHH reaches its own emulated final state.

The subject line specifies DD, not DDD.

The "correctly emulated by HHH" is irrelevant. It does not matter
whether
HHH emulates correctly or partially or incorrectly or not at all. What >>>> matters is whether the answer it gives agrees with the truth about the >>>> termination of DD().

The correctly emulated DD specifies the behavior of the input
to HHH(DD) as opposed to and contrast with the behavior of DD().
No termination analyzer reports on non-inputs.

If the answer returned by HHH(DD) does not agree with the actual
behaviour of DD() then HHH does not meet the requirements of a
halt decider nor even a partial halt decider.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

This input includes the HHH that aborts, therefore, the input specifies
a halting program. The non-input is the hypothetical HHH that does not
abort.

Correct simulation is a correct measure of this behavior.

Only when simulated up to the end.

Correct simulation and direct execution only vary when
an input calls its own simulating termination analyzer.
In the case it is the input that rules and non-inputs are
irrelevant.

But there is only one and the same input for the direct execution and
the simulation. The semantics of the x86 language allows only one
behaviour for the code specified in the input. Therefore, the direct
execution an the simulation must see the same behaviour. If not, the
simulation fails.
Taking into account a hypothetical non-input, that does not abort,
causes a premature abort and a failure to reach the final halt state.

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

On 09/08/2025 07:41, Fred. Zwarts wrote:

Op 08.aug.2025 om 17:40 schreef olcott:

<snip>

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

This input includes the HHH that aborts

An HHH that aborts is not a termination analyser. By failing to
report, it fails in its task. If HHH doesn't return, he doesn't
have a program worth spit. I can get better results with a PRNG.

, therefore, the input
specifies a halting program.

Correct, but HHH fails to communicate this fact to its caller.

Correct simulation is a correct measure of this behavior.

Only when simulated up to the end.

Whether he simulates and up to how far is, I think, irrelevant.
What matters is what HHH reports to its caller.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 09/08/2025 14:11, olcott wrote:

<snip>

Line 996 matches the
*recursive simulation non-halting behavior pattern*

if (current->Simplified_Opcode == CALL) // line 996

is not an argument against the requirement for HHH to report a
result to its caller..

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 09/08/2025 16:36, olcott wrote:

On 8/9/2025 8:19 AM, Richard Heathfield wrote:

On 09/08/2025 14:11, olcott wrote:

<snip>

Line 996 matches the
*recursive simulation non-halting behavior pattern*

if (current->Simplified_Opcode == CALL) // line 996

is not an argument against the requirement for HHH to report a
result to its caller..

Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞,
Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn

That's not an argument either. It's just UTF-8 on speed.

Use your words.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 09/08/2025 17:20, Mike Terry wrote:

On 09/08/2025 08:41, Richard Heathfield wrote:

On 09/08/2025 07:41, Fred. Zwarts wrote:

Op 08.aug.2025 om 17:40 schreef olcott:

<snip>

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

This input includes the HHH that aborts

An HHH that aborts is not a termination analyser. By failing to
report, it fails in its task. If HHH doesn't return, he doesn't
have a program worth spit. I can get better results with a PRNG.

You're misunderstanding the usage of "aborts".  It refers to HHH
aborting the emulation it is performing - in other words,  HHH
simply decides to quit its instruction emulation loop, and
proceeds to do something else, like returning 0 or 1.

Okay, fair enough. It was one of the three possible options:
return true, return false, or don't return. If we eliminate it,
that leaves two options - return true (which we know is wrong),
or return false (which we also know is wrong).

HHH itself
does not stop running when it aborts its emulation.  (There is a
POSIX abort() function,

And a C function by the same name.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

On 09/08/2025 08:41, Richard Heathfield wrote:

On 09/08/2025 07:41, Fred. Zwarts wrote:

Op 08.aug.2025 om 17:40 schreef olcott:

<snip>

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

This input includes the HHH that aborts

An HHH that aborts is not a termination analyser. By failing to report, it fails in its task. If HHH
doesn't return, he doesn't have a program worth spit. I can get better results with a PRNG.

You're misunderstanding the usage of "aborts". It refers to HHH aborting the emulation it is
performing - in other words, HHH simply decides to quit its instruction emulation loop, and
proceeds to do something else, like returning 0 or 1. HHH itself does not stop running when it
aborts its emulation. (There is a POSIX abort() function, but that is something else. A function
calling POSIX abort() is effectively terminating itself, and control never returns to its caller.)


Mike.

, therefore, the input specifies a halting program.

Correct, but HHH fails to communicate this fact to its caller.

Correct simulation is a correct measure of this behavior.

Only when simulated up to the end.

Whether he simulates and up to how far is, I think, irrelevant. What matters is what HHH reports to
its caller.

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

On 09/08/2025 18:20, olcott wrote:

Whenever I say things completely enough that they
can be understood these words are ignored.

Ask yourself why.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

Op 09.aug.2025 om 16:39 schreef olcott:

On 8/9/2025 1:41 AM, Fred. Zwarts wrote:

Op 08.aug.2025 om 17:40 schreef olcott:

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

This input includes the HHH that aborts, therefore, the input
specifies a halting program. The non-input is the hypothetical HHH
that does not abort.

It is incorrect for HHH(DD) to report on the behavior
of DD() after HHH has aborted its simulation.

It is incorrect to report on the behaviour of DD when bug prevent that
HHH can see that behaviour.

This is the same thing as believing that one never needs
to eat entirely on the basis of knowing that one will not
need to eat after one has eaten. This misconception will
cause death by starvation.

Incorrect. It is not the same thing.

It is incorrect to report non-termination for a program that has code to
abort and halt, only because HHH fails to see that specification in the
input, where other simulators prove that this is specified in the exact
same input..

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

On 2025-08-08 14:59:44 +0000, olcott said:

On 8/8/2025 2:06 AM, Richard Heathfield wrote:

On 08/08/2025 07:59, Mikko wrote:

On 2025-08-07 12:56:38 +0000, olcott said:

<snip>

The correctly emulated DD specifies the behavior of the input
to HHH(DD) as opposed to and contrast with the behavior of DD().
No termination analyzer reports on non-inputs.

If the answer returned by HHH(DD) does not agree with the actual
behaviour of DD() then HHH does not meet the requirements of a
halt decider nor even a partial halt decider.

True enough.

Perhaps more importantly, it's hard to imagine a clearer case of weasel
words. DD is clearly an input to HHH(DD), and to claim otherwise is
just bizarre.

It may be very difficult to understand, yet the behavior
of non-inputs does not count.

It is easy to understand but only if you first understand that 4 = 5.

--
Mikko

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

On 2025-08-08 15:40:43 +0000, olcott said:

On 8/8/2025 1:59 AM, Mikko wrote:

On 2025-08-07 12:56:38 +0000, olcott said:

On 8/7/2025 2:36 AM, Mikko wrote:

On 2025-08-06 11:20:04 +0000, olcott said:

On 8/6/2025 2:09 AM, Mikko wrote:

On 2025-08-05 15:17:53 +0000, olcott said:

On 8/5/2025 2:14 AM, Mikko wrote:

On 2025-08-04 21:55:28 +0000, olcott said:

Simulating Termination Analyzer HHH correctly simulates its input until:
(a) Detects a non-terminating behavior pattern: abort simulation and return 0.
(b) Simulated input reaches its simulated "return" statement: return 1.

int DD()
{
   int Halt_Status = HHH(DD);
   if (Halt_Status)
     HERE: goto HERE;
   return Halt_Status;
}

Can you see that DD correctly simulated by HHH demonstrates the >>>>>>>>> recursive simulation non halting behavior pattern that cannot possibly
reach its own "if" statement?

No, we can't hallucinate that. HHH does not demostrate. It simply reports
incorrectly.

*This process is known as cooperative multi-tasking*

Irrelevant. What matters is that a recursion is not a non-halting pattern.

void Infinite_Recursion()
{
   Infinite_Recursion();
   return;
}

For example, there is a recusion in 5! = 5 * (4!) and more generally in >>>>>> (n + 1)! = (n + 1) * n! but there is non-halting pattern there.

Likewise there is a recursive simulation in HHH(DD) but no non-halting >>>>>> pattern.

Then you must know how DDD correctly emulated
by HHH reaches its own emulated final state.

The subject line specifies DD, not DDD.

The "correctly emulated by HHH" is irrelevant. It does not matter whether >>>> HHH emulates correctly or partially or incorrectly or not at all. What >>>> matters is whether the answer it gives agrees with the truth about the >>>> termination of DD().

The correctly emulated DD specifies the behavior of the input
to HHH(DD) as opposed to and contrast with the behavior of DD().
No termination analyzer reports on non-inputs.

If the answer returned by HHH(DD) does not agree with the actual
behaviour of DD() then HHH does not meet the requirements of a
halt decider nor even a partial halt decider.

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

It may be very difficult to understand, yet whatever the problem
statement says does count.

--
Mikko

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

On 10/08/2025 10:03, Mikko wrote:

On 2025-08-08 15:40:43 +0000, olcott said:

<snip>

It may be very difficult to understand, yet the behavior
of non-inputs does not count. Simulating termination
analyzers are only accountable for the behavior that their
inputs specify.

It may be very difficult to understand, yet whatever the problem
statement says does count.

Quite. If olcott spent half the time thinking that he spends
trying to be patronising, he might actually figure out why
everybody is laughing so much at his twisty turns.

Code contains syntax errors to this day.
HHH returns the wrong answer.
Simulation fails to simulate.
No strategy for tackling Turing's twisted tail.
Input is not an input, apparently.
Chat bots prove he's right, until they suddenly don't.
And now he has a bug, which he holds up as evidence of correctness.

I suspect I've missed out rather a lot, but if I don't post soon
I might just swallow a knuckle.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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