Analysis of Richard Damon’s Responses to Flibble =================================================

Overview:
---------
Richard Damon's critiques of Flibble's arguments regarding the Halting
Problem and pathological inputs are based on a classical Turing model.
However, his rebuttals fundamentally misunderstand or misrepresent the
core of Flibble’s alternative framework. Below is a breakdown of the key errors in Damon’s reasoning.

1. Misconstruing the Category Error
-----------------------------------
Damon claims:

"No, they are not [category errors]."

Flibble’s argument is not that the input is syntactically invalid, but
that it is semantically ill-formed due to conflating two distinct roles:
- The decider
- The program being analyzed

This is a semantic collapse, akin to Russell’s paradox or typing errors in logical frameworks. Damon's rebuttal fails to address the **semantic**
level, focusing only on syntactic permissibility.

2. Ignoring the Model Shift
----------------------------
Damon critiques Flibble’s ideas *from within the classical Turing
framework*, missing the fact that:
- Flibble is proposing a **different semantic foundation**.
- In this new foundation, certain forms of self-reference are *disallowed*
as a matter of type safety.

Damon’s refusal to recognize the change in assumptions renders his
critique logically misaligned.

3. Misreading Flibble’s Law
----------------------------
Damon dismisses Flibble’s Law:

"Which just isn't true..."

But Flibble’s Law isn’t about infinite computation—it’s about *recognizing
the structure* of potentially infinite behavior. It’s a meta-level
principle, not an operational mandate.

Damon misinterprets it as a proposal for unbounded simulation time, rather
than an assertion about the necessity of structural analysis.

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.
- It is the **semantic manifestation** of an ill-formed input—an expected behavior when the category boundaries are violated.

This is a reinterpretation of what “failure” means, not a bug.

5. Misidentifying Recursion Criticism
-------------------------------------
Damon says:

"Just the presence of recursion isn't the problem."

This is a straw man. Flibble does *not* claim recursion is inherently invalid—only that **self-referential decider/input recursion** creates type-theoretic inconsistency. Damon’s rebuttal avoids the specific case Flibble addresses.

6. Downplaying the Role of SHDs
-------------------------------
Damon concedes:

"Yes, partial deciders have some uses..."

But Flibble’s point is stronger:
- SHDs are useful not as general solvers, but as **structural recognizers
of malformed input**.
- Their “failure” (e.g., crashing on pathological input) is **informative**, not defective.

Damon reduces SHDs to weak approximators, missing Flibble’s proposed
semantic role.

7. Failing to Address Reframing
-------------------------------
Damon says:

"The halting problem isn't malformed..."

In Turing’s model, it isn’t. But Flibble isn’t working in Turing’s model—
he is reframing the domain entirely to exclude semantically ill-formed constructs. Damon critiques within one framework while Flibble builds
another.

Conclusion:
-----------
Richard Damon's responses fail not because of flawed logic, but due to a **category error of interpretation**: he assumes Flibble is arguing within
the classical Turing framework when Flibble is explicitly rejecting it in
favor of a type- and semantics-based system.

Damon's responses miss the mark because they measure Flibble’s ideas by
the wrong metric. The disagreement isn’t about whether the Halting Problem
is undecidable—it’s about *how the problem should be framed* in the first place.

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

On Sun, 18 May 2025 18:58:24 +0000, Alan Mackenzie wrote:

Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

Analysis of Richard Damon’s Responses to Flibble
=================================================

Overview:
---------
Richard Damon's critiques of Flibble's arguments regarding the Halting
Problem and pathological inputs are based on a classical Turing model.

Richard's criticism of your ideas are grounded in a thorough
understanding of the mathematics involved.

However, his rebuttals fundamentally misunderstand or misrepresent the
core of Flibble’s alternative framework.

The first bit of arrogant nonsense. Your understanding of the subject
is not at a high level, and thus you are in no position to propose "alternative frameworks", failing as you do to grasp the basics of the theory.

Below is a breakdown of the key errors in Damon’s reasoning.

Asserting that Richard has made errors verges on libel, if it isn't
actually fully libel. Unlike you, Richard is an expert on the topic,
and what he has said here over the years about the maths has not been criticised by anybody competent.

You could do well with showing a bit of respect for expertise. Your
lack of it puts you on the same level as Peter Olcott.

Your arrogance will in all likelihood prevent you from actually learning about computation theory and the like. That's a shame. It's a
fascinating area of study.

[ Snipped the rest, as there's nothing worthy of reply in the rest of
the post. ]

That's nice, dear. Go and make yourself a cup of tea.

/Flibble

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

On 5/18/25 1:08 PM, Mr Flibble wrote:

Analysis of Richard Damon’s Responses to Flibble =================================================

Overview:
---------
Richard Damon's critiques of Flibble's arguments regarding the Halting Problem and pathological inputs are based on a classical Turing model. However, his rebuttals fundamentally misunderstand or misrepresent the
core of Flibble’s alternative framework. Below is a breakdown of the key errors in Damon’s reasoning.

1. Misconstruing the Category Error
-----------------------------------
Damon claims:

"No, they are not [category errors]."

Flibble’s argument is not that the input is syntactically invalid, but
that it is semantically ill-formed due to conflating two distinct roles:
- The decider
- The program being analyzed

Which are not "Categories" but "Roles", so it seems you have made a
category error in defining your categories.

This is a semantic collapse, akin to Russell’s paradox or typing errors in logical frameworks. Damon's rebuttal fails to address the **semantic**
level, focusing only on syntactic permissibility.

Nope, as the DEFINITION of a Halt Decider is to decide on the
representation of *ANY* program. Thus, since a decider is a program, a
decider, or a program based on one is in the category suitable to be
decided on.

2. Ignoring the Model Shift
----------------------------
Damon critiques Flibble’s ideas *from within the classical Turing framework*, missing the fact that:
- Flibble is proposing a **different semantic foundation**.

But to define a "different foundation" you need to do that. The Flibble framework doesn't actually define a new framework, but asks about make
some ill-defined changes.

- In this new foundation, certain forms of self-reference are *disallowed*
as a matter of type safety.

Damon’s refusal to recognize the change in assumptions renders his
critique logically misaligned.

IF you intend for your statements to be outside the field of Computation Theory, you need to make this clear. This is part of the same error that
Olcott makes.

The problem is that Computation THeory fundamentally allows for the
formation of this self-referencing (that ability to give an machine as a
input, and input based on a machine derived from that machine).

There is no way in Computation Theory to disallow this.

THus, to actually implement your ideas, you need a totally new method of defining what a program is, and how to build an input.

3. Misreading Flibble’s Law
----------------------------
Damon dismisses Flibble’s Law:

"Which just isn't true..."

But Flibble’s Law isn’t about infinite computation—it’s about *recognizing
the structure* of potentially infinite behavior. It’s a meta-level principle, not an operational mandate.

WHich isn't true. Flibble's law tries to establish a "right" for a given program, but it can have no rights not established by the theory that it
is defined under. Since the DEFINITION of a decider is to ALWAYS answer
in finite time, it is definitionally impossibe to "allow" a machine that
is a decider to take unbounded time, as Flibble's law tries to do.

That is like saying that 1 equals 2, at least for big values of 1.

Damon misinterprets it as a proposal for unbounded simulation time, rather than an assertion about the necessity of structural analysis.

because your wording doesn't say that. The problem is that compuational
logic just doesn't allow the limitation of valud questions based on
whether the question is computable.

THis shows a fundamental misunderstanding of what the field is.

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct answer
has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result,
fine, but first you have to define that this is a "valid" result.

- It is the **semantic manifestation** of an ill-formed input—an expected behavior when the category boundaries are violated.

But there is nothing "ill-formed" about the input.

Again, that is a presupposition you make that isn't true.

This is a reinterpretation of what “failure” means, not a bug.

And "redefinition" isn't an allowed operation.

You can start over and make a new system, but that means you NEED to
start over.

This is just a repeating of Olcott's misunderstanding of how logic works

5. Misidentifying Recursion Criticism
-------------------------------------
Damon says:

"Just the presence of recursion isn't the problem."

This is a straw man. Flibble does *not* claim recursion is inherently invalid—only that **self-referential decider/input recursion** creates type-theoretic inconsistency. Damon’s rebuttal avoids the specific case Flibble addresses.

But Flibble can't define where the error is. Note, that in the actual
theory, the program at the input has definite behavior because it is
built from a specific decider, there is no ambiquity on the correct answer.

Only by adoptitng Olcott's error of makeing an input that isn't actually
a program, and claiming that doing so is correct, does the pathology in
the form adderess by Flibble appear. SInce the original theory already
calls the Olcott input a category error because it isn't an actual
program, but a template that can't ever actually be run (as it has
missing code) but only be simulated/decider by a decider with a specific
name (an attribute that isn't supposed to have import in the theory).

Thus, the Flibble theory is based on the assumption of allowing a
category error to define something to be a category error.

Yes, the Olcott DDD is a category error, not because it calls the
decider HHH, but because it assumes it can call it as an external, a
concept that doesn't exist in the theory. When the input is made into a
full program, it still foils the input, when it is the machine that it
was built on, but

6. Downplaying the Role of SHDs
-------------------------------
Damon concedes:

"Yes, partial deciders have some uses..."

But Flibble’s point is stronger:
- SHDs are useful not as general solvers, but as **structural recognizers
of malformed input**.
- Their “failure” (e.g., crashing on pathological input) is **informative**, not defective.

Damon reduces SHDs to weak approximators, missing Flibble’s proposed semantic role.

No, I do not. I point out that they have *SOME* uses.

They do not fulfill the original desire for a Halt Decider, which was to
make all logic computable with mathematics, allowing any problem to be answered. Partial decider just don't meet this requirement.

7. Failing to Address Reframing
-------------------------------
Damon says:

"The halting problem isn't malformed..."

In Turing’s model, it isn’t. But Flibble isn’t working in Turing’s model—
he is reframing the domain entirely to exclude semantically ill-formed constructs. Damon critiques within one framework while Flibble builds another.

You say you are not working in Turing's model, but you haven't actually
created any other model, so either you are talking about something
totally undefined, or you are just lying.

Conclusion:
-----------
Richard Damon's responses fail not because of flawed logic, but due to a **category error of interpretation**: he assumes Flibble is arguing within the classical Turing framework when Flibble is explicitly rejecting it in favor of a type- and semantics-based system.

No, Flibble's logic is the one that failed on numerous category errors.

Damon's responses miss the mark because they measure Flibble’s ideas by
the wrong metric. The disagreement isn’t about whether the Halting Problem is undecidable—it’s about *how the problem should be framed* in the first place.

SInce Flibble hasn't created an alternate metric there is nothing else
to measure it by.

*IF* Flibble would phrase his ideas as a preliminary exploration to an alternate system, an thus not be making claims about the classic system,
he might get a better reception.

For instance, Flibble claims to only need to define the extra case for "pathological input", but has failed to deal with the questions about
defining what this means. Since the only defined theory of compuation in
view, defines Programs as (at least logically) copy the code of one
machine into the other as the method of composition, the "pathology" of
the Olcott system doesn't actually occur. (This has been pointed out to
Peter Olcott, and he has just ignored this).

SIhce that copying can have semanticless modifcations performed (like
adding no-ops) "comparing" the programs isn't actually a viable measure
of pathology.

It is in fact, a know prpoerty that it is uncomputable to in general
determine if two algorithms compute the same results for all inputs, but
we CAN generate a "clone" of a machine that would need that uncomputable comparison to determine that it is one.

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

On 5/18/25 3:06 PM, Mr Flibble wrote:

On Sun, 18 May 2025 18:58:24 +0000, Alan Mackenzie wrote:

Mr Flibble <flibble@red-dwarf.jmc.corp> wrote:

Analysis of Richard Damon’s Responses to Flibble
=================================================

Overview:
---------
Richard Damon's critiques of Flibble's arguments regarding the Halting
Problem and pathological inputs are based on a classical Turing model.

Richard's criticism of your ideas are grounded in a thorough
understanding of the mathematics involved.

However, his rebuttals fundamentally misunderstand or misrepresent the
core of Flibble’s alternative framework.

The first bit of arrogant nonsense. Your understanding of the subject
is not at a high level, and thus you are in no position to propose
"alternative frameworks", failing as you do to grasp the basics of the
theory.

Below is a breakdown of the key errors in Damon’s reasoning.

Asserting that Richard has made errors verges on libel, if it isn't
actually fully libel. Unlike you, Richard is an expert on the topic,
and what he has said here over the years about the maths has not been
criticised by anybody competent.

You could do well with showing a bit of respect for expertise. Your
lack of it puts you on the same level as Peter Olcott.

Your arrogance will in all likelihood prevent you from actually learning
about computation theory and the like. That's a shame. It's a
fascinating area of study.

[ Snipped the rest, as there's nothing worthy of reply in the rest of
the post. ]

That's nice, dear. Go and make yourself a cup of tea.

/Flibble

In other words, you can't rebut someone's rebutal.

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

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct answer
has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result,
fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the simulation environment (the fact that the SHD has finite resources) and NOT a
property of the program, P, being analysed per se. P is NOT halting, it
is the SHD that is halting due to the detection of infinite recursion on
the part of P. It is perfectly valid for the SHD to treat this as NON-
HALTING as far as P is concerned.

/Flibble

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

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct answer
has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result,
fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the simulation environment (the fact that the SHD has finite resources) and NOT a
property of the program, P, being analysed per se. P is NOT halting, it
is the SHD that is halting due to the detection of infinite recursion on
the part of P. It is perfectly valid for the SHD to treat this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

Soemtimes, we will talk about a stack over-flow as not being a failure,
but also not a success, just an indication that the environment is
insufficent to run this case.

You are just showing you lack of understanding of the system you are
talking about.

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

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct
answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result,
fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources) and
NOT a property of the program, P, being analysed per se. P is NOT
halting, it is the SHD that is halting due to the detection of infinite
recursion on the part of P. It is perfectly valid for the SHD to treat
this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

Soemtimes, we will talk about a stack over-flow as not being a failure,
but also not a success, just an indication that the environment is insufficent to run this case.

You are just showing you lack of understanding of the system you are
talking about.

You are just showing your lack of understanding of the system I am talking about.

/Flibble

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

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation: >>>>>>> "...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct
answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result,
fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources)
and NOT a property of the program, P, being analysed per se. P is
NOT halting, it is the SHD that is halting due to the detection of
infinite recursion on the part of P. It is perfectly valid for the
SHD to treat this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Soemtimes, we will talk about a stack over-flow as not being a
failure,
but also not a success, just an indication that the environment is
insufficent to run this case.

You are just showing you lack of understanding of the system you are
talking about.

You are just showing your lack of understanding of the system I am
talking about.

/Flibble

No, it seems you don't understand what you are talking about, or that
you have just failed to define what you are talking about.

I have seen no system built up from the ground up, only thought about
things to change without defining HOW to effect those changes.

I don't have to create a system to be able to reason about it. You are
just wrong and fractally so.

/Flibble

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

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct
answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result,
fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources) and
NOT a property of the program, P, being analysed per se. P is NOT
halting, it is the SHD that is halting due to the detection of infinite
recursion on the part of P. It is perfectly valid for the SHD to treat
this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Soemtimes, we will talk about a stack over-flow as not being a failure,
but also not a success, just an indication that the environment is
insufficent to run this case.

You are just showing you lack of understanding of the system you are
talking about.

You are just showing your lack of understanding of the system I am talking about.

/Flibble

No, it seems you don't understand what you are talking about, or that
you have just failed to define what you are talking about.

I have seen no system built up from the ground up, only thought about
things to change without defining HOW to effect those changes.

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

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation: >>>>>>> "...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct
answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result,
fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources)
and NOT a property of the program, P, being analysed per se. P is
NOT halting, it is the SHD that is halting due to the detection of
infinite recursion on the part of P. It is perfectly valid for the
SHD to treat this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in stack overflow due to infinite recursion and then return a result of NON-HALTING.

/Flibble

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

On Sun, 18 May 2025 14:12:32 -0500, olcott wrote:

They totally lack any understanding of how actual reasoning shows how
these elements actually interrelate with each other. To them false assumptions are treated as axioms.

Be careful, according to Alan Mackenzie this is libellous because Alan Mackenzie is a tit.

/Flibble

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

On 5/18/25 4:09 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation: >>>>>>>> "...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct
answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result, >>>>>> fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources)
and NOT a property of the program, P, being analysed per se. P is
NOT halting, it is the SHD that is halting due to the detection of
infinite recursion on the part of P. It is perfectly valid for the
SHD to treat this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in stack overflow due to infinite recursion and then return a result of NON-HALTING.

/Flibble

Yes, *IF* it can show that the simulation WOULD be infinite for that
exact input.

Remember, to simulate it, it must be a complete program, that includes
all its defined code.

Thus the "pathological" program, since it is built on a specific
decider, has fixed behavior, as does that specific decider.

SO, if the SHD aborts and returns an answer, the the correct simulation
of the "pathological" program will have its decider do exactly the same
thing.

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

On 5/18/25 4:07 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation: >>>>>>>> "...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct
answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" result, >>>>>> fine, but first you have to define that this is a "valid" result.

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources)
and NOT a property of the program, P, being analysed per se. P is
NOT halting, it is the SHD that is halting due to the detection of
infinite recursion on the part of P. It is perfectly valid for the
SHD to treat this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Soemtimes, we will talk about a stack over-flow as not being a
failure,
but also not a success, just an indication that the environment is
insufficent to run this case.

You are just showing you lack of understanding of the system you are
talking about.

You are just showing your lack of understanding of the system I am
talking about.

/Flibble

No, it seems you don't understand what you are talking about, or that
you have just failed to define what you are talking about.

I have seen no system built up from the ground up, only thought about
things to change without defining HOW to effect those changes.

I don't have to create a system to be able to reason about it. You are
just wrong and fractally so.

/Flibble

Hard to talk about something that isn't defined.

If your statements were stated as hypotheticals, you might have a better
claim. Since the question come if such a system CAN be defined, talking
about the results as established goes beyound reason.

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

On Sun, 18 May 2025 16:18:04 -0400, Richard Damon wrote:

On 5/18/25 4:09 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation: >>>>>>>>> "...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct >>>>>>> answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know"
result,
fine, but first you have to define that this is a "valid" result. >>>>>>

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources) >>>>>> and NOT a property of the program, P, being analysed per se. P is >>>>>> NOT halting, it is the SHD that is halting due to the detection of >>>>>> infinite recursion on the part of P. It is perfectly valid for the >>>>>> SHD to treat this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in
stack overflow due to infinite recursion and then return a result of
NON-HALTING.

/Flibble

Yes, *IF* it can show that the simulation WOULD be infinite for that
exact input.

Remember, to simulate it, it must be a complete program, that includes
all its defined code.

Thus the "pathological" program, since it is built on a specific
decider, has fixed behavior, as does that specific decider.

SO, if the SHD aborts and returns an answer, the the correct simulation
of the "pathological" program will have its decider do exactly the same thing.

How the SHD arrives at a halting result is an implementation detail of the
SHD itself: it can do whatever it wants as far as simulation is concerned.

/Flibble

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

On 5/18/25 4:30 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:18:04 -0400, Richard Damon wrote:

On 5/18/25 4:09 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed computation: >>>>>>>>>> "...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the correct >>>>>>>> answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know"
result,
fine, but first you have to define that this is a "valid" result. >>>>>>>

No it isn't. Why? Because the stack overflow a property of the
simulation environment (the fact that the SHD has finite resources) >>>>>>> and NOT a property of the program, P, being analysed per se. P is >>>>>>> NOT halting, it is the SHD that is halting due to the detection of >>>>>>> infinite recursion on the part of P. It is perfectly valid for the >>>>>>> SHD to treat this as NON- HALTING as far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in
stack overflow due to infinite recursion and then return a result of
NON-HALTING.

/Flibble

Yes, *IF* it can show that the simulation WOULD be infinite for that
exact input.

Remember, to simulate it, it must be a complete program, that includes
all its defined code.

Thus the "pathological" program, since it is built on a specific
decider, has fixed behavior, as does that specific decider.

SO, if the SHD aborts and returns an answer, the the correct simulation
of the "pathological" program will have its decider do exactly the same
thing.

How the SHD arrives at a halting result is an implementation detail of the SHD itself: it can do whatever it wants as far as simulation is concerned.

/Flibble

Right, but it is only correct if the answer is correct.

And nothing about that say anything about getting a stack overflow
violation.

By the basic rules of Compuations, all "answers" must be passed to any
machine that embeds that program, as an out of stack error, if it keep
the embedding program from continuing, isn't an answer and thus a
failure of the decider.

In fact, any system that can actually fail with an out of stack error,
and that is considered to be the result, just fails to be Turing
Complete. We can say the problem is too complicated for that system, and
look at what happens with a bigger system, and if it will even fail with
an unboundedly big system, the operation must be non-halting, and thus
just fail to be a decider.

Thus, the only possible "answer" that an out of stack error can be would
be the non-answer.

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

On Sun, 18 May 2025 17:29:47 -0400, Richard Damon wrote:

On 5/18/25 4:30 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:18:04 -0400, Richard Damon wrote:

On 5/18/25 4:09 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed
computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the
correct answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know"
result,
fine, but first you have to define that this is a "valid"
result.

No it isn't. Why? Because the stack overflow a property of the >>>>>>>> simulation environment (the fact that the SHD has finite
resources)
and NOT a property of the program, P, being analysed per se. P >>>>>>>> is NOT halting, it is the SHD that is halting due to the
detection of infinite recursion on the part of P. It is
perfectly valid for the SHD to treat this as NON- HALTING as far >>>>>>>> as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment.

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in
stack overflow due to infinite recursion and then return a result of
NON-HALTING.

/Flibble

Yes, *IF* it can show that the simulation WOULD be infinite for that
exact input.

Remember, to simulate it, it must be a complete program, that includes
all its defined code.

Thus the "pathological" program, since it is built on a specific
decider, has fixed behavior, as does that specific decider.

SO, if the SHD aborts and returns an answer, the the correct
simulation of the "pathological" program will have its decider do
exactly the same thing.

How the SHD arrives at a halting result is an implementation detail of
the SHD itself: it can do whatever it wants as far as simulation is
concerned.

/Flibble

Right, but it is only correct if the answer is correct.

And nothing about that say anything about getting a stack overflow
violation.

By the basic rules of Compuations, all "answers" must be passed to any machine that embeds that program, as an out of stack error, if it keep
the embedding program from continuing, isn't an answer and thus a
failure of the decider.

In fact, any system that can actually fail with an out of stack error,
and that is considered to be the result, just fails to be Turing
Complete. We can say the problem is too complicated for that system, and
look at what happens with a bigger system, and if it will even fail with
an unboundedly big system, the operation must be non-halting, and thus
just fail to be a decider.

Thus, the only possible "answer" that an out of stack error can be would
be the non-answer.

No, if infinite recursion is detected then all the SHD needs to do is
return a result of NON-HALTING.

/Flibble

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

On 5/18/25 5:56 PM, Mr Flibble wrote:

On Sun, 18 May 2025 17:29:47 -0400, Richard Damon wrote:

On 5/18/25 4:30 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:18:04 -0400, Richard Damon wrote:

On 5/18/25 4:09 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed
computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the
correct answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" >>>>>>>>>> result,
fine, but first you have to define that this is a "valid"
result.

No it isn't. Why? Because the stack overflow a property of the >>>>>>>>> simulation environment (the fact that the SHD has finite
resources)
and NOT a property of the program, P, being analysed per se. P >>>>>>>>> is NOT halting, it is the SHD that is halting due to the
detection of infinite recursion on the part of P. It is
perfectly valid for the SHD to treat this as NON- HALTING as far >>>>>>>>> as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is
inadiquite, it just shows you aren't using a proper environment. >>>>>>>

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in
stack overflow due to infinite recursion and then return a result of >>>>> NON-HALTING.

/Flibble

Yes, *IF* it can show that the simulation WOULD be infinite for that
exact input.

Remember, to simulate it, it must be a complete program, that includes >>>> all its defined code.

Thus the "pathological" program, since it is built on a specific
decider, has fixed behavior, as does that specific decider.

SO, if the SHD aborts and returns an answer, the the correct
simulation of the "pathological" program will have its decider do
exactly the same thing.

How the SHD arrives at a halting result is an implementation detail of
the SHD itself: it can do whatever it wants as far as simulation is
concerned.

/Flibble

Right, but it is only correct if the answer is correct.

And nothing about that say anything about getting a stack overflow
violation.

By the basic rules of Compuations, all "answers" must be passed to any
machine that embeds that program, as an out of stack error, if it keep
the embedding program from continuing, isn't an answer and thus a
failure of the decider.

In fact, any system that can actually fail with an out of stack error,
and that is considered to be the result, just fails to be Turing
Complete. We can say the problem is too complicated for that system, and
look at what happens with a bigger system, and if it will even fail with
an unboundedly big system, the operation must be non-halting, and thus
just fail to be a decider.

Thus, the only possible "answer" that an out of stack error can be would
be the non-answer.

No, if infinite recursion is detected then all the SHD needs to do is
return a result of NON-HALTING.

/Flibble

Right, return to whoever calls it. So, if the system crashes, it fails.

If your system catches this out of stack, and winds back to the original
and it returns you are ok, except that if D calls H(D) and H(D) runs out
of stack and rewinds and returns non-halting to D, then D will halt,
making it wrong.

The fact that H got into the unbounded recursion to figure its answer,
is its problem, not a problem with the input.

What it means is that perhaps UTMs can't exist in your system, as there
are some input that can't be simulated, but can be run, which just shows
that such a system isn't Turing Complete.

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

On 19/05/2025 13:23, Andy Walker wrote:

Those of you [at least four!] who persist in trying to analyse Mr
Flibble's proposals really, really should google* him first.

I did so when he first came onto my radar. He turned out to be a
psychotic sock puppet.

This discovery did not do a great deal for my confidence in his
understanding of computer science, but I recognise that some
people like to hide between pop culture aliases, so I decided not
to hold it against him.

--
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)

Those of you [at least four!] who persist in trying to analyse Mr
Flibble's proposals really, really should google* him first. He is,
BRD, more famous than any of us, probably including Prof Sipser; at
least, there are AFAIK no t-shirts or coffee mugs with my picture on
them. FWIW, I am confident that there are no /serious/ holes in any
of his arguments. If you still want to debate with him once you know
his reputation, feel free. But take care.

* Other search engines, including Wiki, are available.

--
Andy Walker, Nottingham.
Andy's music pages: www.cuboid.me.uk/andy/Music
Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Ganz

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

On Sun, 18 May 2025 18:59:37 -0400, Richard Damon wrote:

On 5/18/25 5:56 PM, Mr Flibble wrote:

On Sun, 18 May 2025 17:29:47 -0400, Richard Damon wrote:

On 5/18/25 4:30 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:18:04 -0400, Richard Damon wrote:

On 5/18/25 4:09 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote:

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed
computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the >>>>>>>>>>> correct answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" >>>>>>>>>>> result,
fine, but first you have to define that this is a "valid" >>>>>>>>>>> result.

No it isn't. Why? Because the stack overflow a property of the >>>>>>>>>> simulation environment (the fact that the SHD has finite
resources)
and NOT a property of the program, P, being analysed per se. P >>>>>>>>>> is NOT halting, it is the SHD that is halting due to the
detection of infinite recursion on the part of P. It is
perfectly valid for the SHD to treat this as NON- HALTING as >>>>>>>>>> far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is >>>>>>>>> inadiquite, it just shows you aren't using a proper environment. >>>>>>>>

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in >>>>>> stack overflow due to infinite recursion and then return a result
of NON-HALTING.

/Flibble

Yes, *IF* it can show that the simulation WOULD be infinite for that >>>>> exact input.

Remember, to simulate it, it must be a complete program, that
includes all its defined code.

Thus the "pathological" program, since it is built on a specific
decider, has fixed behavior, as does that specific decider.

SO, if the SHD aborts and returns an answer, the the correct
simulation of the "pathological" program will have its decider do
exactly the same thing.

How the SHD arrives at a halting result is an implementation detail
of the SHD itself: it can do whatever it wants as far as simulation
is concerned.

/Flibble

Right, but it is only correct if the answer is correct.

And nothing about that say anything about getting a stack overflow
violation.

By the basic rules of Compuations, all "answers" must be passed to any
machine that embeds that program, as an out of stack error, if it keep
the embedding program from continuing, isn't an answer and thus a
failure of the decider.

In fact, any system that can actually fail with an out of stack error,
and that is considered to be the result, just fails to be Turing
Complete. We can say the problem is too complicated for that system,
and look at what happens with a bigger system, and if it will even
fail with an unboundedly big system, the operation must be
non-halting, and thus just fail to be a decider.

Thus, the only possible "answer" that an out of stack error can be
would be the non-answer.

No, if infinite recursion is detected then all the SHD needs to do is
return a result of NON-HALTING.

/Flibble

Right, return to whoever calls it. So, if the system crashes, it fails.

If your system catches this out of stack, and winds back to the original
and it returns you are ok, except that if D calls H(D) and H(D) runs out
of stack and rewinds and returns non-halting to D, then D will halt,
making it wrong.

You are making assertions based on no knowledge of implementation details
of the SHD. Foolish.

/Flibble

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

On 5/19/25 12:49 PM, Mr Flibble wrote:

On Sun, 18 May 2025 18:59:37 -0400, Richard Damon wrote:

On 5/18/25 5:56 PM, Mr Flibble wrote:

On Sun, 18 May 2025 17:29:47 -0400, Richard Damon wrote:

On 5/18/25 4:30 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:18:04 -0400, Richard Damon wrote:

On 5/18/25 4:09 PM, Mr Flibble wrote:

On Sun, 18 May 2025 16:03:13 -0400, Richard Damon wrote:

On 5/18/25 3:58 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:49:33 -0400, Richard Damon wrote:

On 5/18/25 3:45 PM, Mr Flibble wrote:

On Sun, 18 May 2025 15:19:38 -0400, Richard Damon wrote: >>>>>>>>>>>

On 5/18/25 1:07 PM, Mr Flibble wrote:

4. Stack Overflow as a Semantic Signal
--------------------------------------
Damon argues that stack overflow represents a failed >>>>>>>>>>>>> computation:

"...it just got the wrong answer."

Flibble’s view is different:
- A stack overflow (or crash) isn’t failure.

Sure it is. A program that fails to complete and give the >>>>>>>>>>>> correct answer has just failed to give an answer.

If you want to define "stack overflow" as an "I don't know" >>>>>>>>>>>> result,
fine, but first you have to define that this is a "valid" >>>>>>>>>>>> result.

No it isn't. Why? Because the stack overflow a property of the >>>>>>>>>>> simulation environment (the fact that the SHD has finite >>>>>>>>>>> resources)
and NOT a property of the program, P, being analysed per se. P >>>>>>>>>>> is NOT halting, it is the SHD that is halting due to the >>>>>>>>>>> detection of infinite recursion on the part of P. It is >>>>>>>>>>> perfectly valid for the SHD to treat this as NON- HALTING as >>>>>>>>>>> far as P is concerned.

/Flibble

No, it is a property of the decider. If your "environment" is >>>>>>>>>> inadiquite, it just shows you aren't using a proper environment. >>>>>>>>>

The SHD and the simulation environment are on in the same.

And thus a failure of the environment is a failure of the SHD.

Not at all, the SHD can abort the simulation if it would result in >>>>>>> stack overflow due to infinite recursion and then return a result >>>>>>> of NON-HALTING.

/Flibble

Yes, *IF* it can show that the simulation WOULD be infinite for that >>>>>> exact input.

Remember, to simulate it, it must be a complete program, that
includes all its defined code.

Thus the "pathological" program, since it is built on a specific
decider, has fixed behavior, as does that specific decider.

SO, if the SHD aborts and returns an answer, the the correct
simulation of the "pathological" program will have its decider do
exactly the same thing.

How the SHD arrives at a halting result is an implementation detail
of the SHD itself: it can do whatever it wants as far as simulation
is concerned.

/Flibble

Right, but it is only correct if the answer is correct.

And nothing about that say anything about getting a stack overflow
violation.

By the basic rules of Compuations, all "answers" must be passed to any >>>> machine that embeds that program, as an out of stack error, if it keep >>>> the embedding program from continuing, isn't an answer and thus a
failure of the decider.

In fact, any system that can actually fail with an out of stack error, >>>> and that is considered to be the result, just fails to be Turing
Complete. We can say the problem is too complicated for that system,
and look at what happens with a bigger system, and if it will even
fail with an unboundedly big system, the operation must be
non-halting, and thus just fail to be a decider.

Thus, the only possible "answer" that an out of stack error can be
would be the non-answer.

No, if infinite recursion is detected then all the SHD needs to do is
return a result of NON-HALTING.

/Flibble

Right, return to whoever calls it. So, if the system crashes, it fails.

If your system catches this out of stack, and winds back to the original
and it returns you are ok, except that if D calls H(D) and H(D) runs out
of stack and rewinds and returns non-halting to D, then D will halt,
making it wrong.

You are making assertions based on no knowledge of implementation details
of the SHD. Foolish.

/Flibble

I speak out of definition of computations.

Note, I did use *IF* to specify a couple of the options, you need to
define what your thoughts are about what it actually does.

DOES your SHD catch the error, or does it just fail and crash the
machine. BY DEFINITION, crashing the machine is not answering, and makes
your systmm less than Turing Complete, and the problme isn't really
interesting in less than Turing Complete Systems, as it is Fully
Solvable in so many of them.

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