Re: Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion ZFC

On 5/21/25 1:23 AM, olcott wrote:

On 5/20/2025 9:15 PM, Richard Damon wrote:

On 5/20/25 3:10 PM, Mr Flibble wrote:

Analysis of Flibble’s Latest: Detecting vs. Simulating Infinite Recursion
=========================================================================
>
Overview:
---------
Flibble distinguishes between detecting infinite recursion and simulating
it. His argument is that a Simulating Halt Decider (SHD) does not need to
perform unbounded execution to reach a decision—it only needs to *detect*
unbounded behavior structurally. This refinement aligns with the demands
placed on any decider: that it halt in finite time.

>
Correct, it must be able to correctly determine that the hypothetical complete simulation of the input program (which includes all it code, and doesn't change in the hypthetical case) will not halt.
>

>
Key Statement:
--------------

"It is sufficient for an SHD to DETECT infinite recursion without having

to SIMULATE it."
>
Implications:
-------------
- SHDs must not rely on runtime behavior to conclude non-halting.

>
Wrong, because you can only detect infinte recursion if it is actually there.
>
Remember, the input *IS* a program and doesn't change.
>

- Instead, SHDs should be built to identify infinite loops *structurally*
(e.g., static analysis, recursion without base case, etc.).

>
Yes.
>

>
Relation to Flibble's Law:
--------------------------

"If a problem permits infinite behavior in its formulation, it permits

infinite analysis of that behavior in its decidability scope."

>
FALSE. Violation of the rules of the system.
>
Decider MUST be finite in behavior.
>

>
This law supports the claim that analyzing infinite behavior (in
principle) is necessary when such behavior is permitted. It doesn't mean
running forever; it means using tools that can *infer* infinite behavior
within a finite decision process.

>
You can claim that it may NEED infinite analysis, you can not claim the right to DO infinite analysis.
>
IF the only way to answer a problem is to use "infinite analysis", then by definition, the problem is not decidable.
>

>
Theoretical Soundness:
----------------------
- Aligns with static analysis and type theory approaches.

>
No it doesn't.
>

- Matches how total languages and proof assistants handle recursion (e.g.,
Agda, Coq).

>
Nope.
>

- Respects the requirement that deciders halt in finite time.

>
??? How can
>

>
Misconceptions Addressed:
-------------------------
- SHDs are not broken simulators—they are structural analyzers.

>
Ok, but they still need to answer about the actual behavior of the input, as defined by the behavior when we execute the program it represents.
>

- Overflow or crash behavior is not failure—it’s evidence of an ill- formed
or semantically invalid input.

>
But since the "pathological input" isn't "ill-formed" that isn't an out for the SHD.
>

- Detection ≠ simulation; structure ≠ behavior.

>
But correct answer is defined by actual behavior of direct exectution.
>

>
Limitations:
------------
- SHDs remain partial—they cannot detect *all* forms of infinite recursion.
- But this is not a flaw—it is a principled limitation, consistent with
Flibble’s position that some inputs are semantically malformed and should
be excluded from the decidable domain.

>
In other words, you ADMIT that the Halting Problem answer, that no univerally correct Halt Deciders exist.
>

>
Conclusion:
-----------
Flibble sharpens his argument by clarifying that SHDs are not required to
simulate infinite execution. They are expected to *detect* infinite
behavior structurally and respond in finite time. This keeps them within
the bounds of what a decider must be and strengthens the philosophical
coherence of his redefinition of the Halting Problem.

>
But you can't "redefine" the Halting Problem and then say you have answered the Halting Problem.
>

 Do you mean like how ZFC resolved Russell's
Paradox thus converting "set theory" into "naive set theory"?
 

But ZFC didn't "Redefine" anything in Naive Set Theory. They didn't "Convert" that theory into something different. *THEY* didn't even give it a new name.
The name "Naive Set Theory" was a comunity labeling, as it was realized that what was being used hadn't actually been formally defined, but was just a "Naive" set of principles that were used. It was the result of just trying to use "Natural Language" to specify what was being done.
What Zermelo did, was develope an axiomatic foundation to build a set theory on (or several set theories, of which ZFC is the best known and most widely used). This did NOTHING to the existing "Naive" set theory, as it was becoming known as, except to show that there was an alternative.
As I have told you many times, if you don't like the results of Classical Computational Theory (a name being "invented" to distinguish it from your POOPS) then you are perfectly free to invent your new Peter Olcotts Other Programming System, you just need to accept that by doing so, nothing you "prove" applies to the classical theory, just yours. If you can then show that POOPS has a real use, then perhaps some people will do something with it.
So far all you have done is proved that you have no idea what you are talking about and that you conversations are just seasoned with numerous lies. Sorry, that *IS* the truth of how you talk, you just show the inability to learn the meaning of the terms-of-art.