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

On 2025-05-25 14:26:47 +0000, olcott said:

On 5/25/2025 5:18 AM, Mikko wrote:

On 2025-05-24 16:38:58 +0000, olcott said:
 

On 5/24/2025 11:24 AM, Mr Flibble wrote:

On Sat, 24 May 2025 11:13:12 -0500, olcott wrote:
 

On 5/24/2025 10:12 AM, dbush wrote:

On 5/24/2025 11:04 AM, olcott wrote:

On 5/23/2025 8:09 PM, dbush wrote:

On 5/23/2025 9:07 PM, olcott wrote:

On 5/23/2025 7:57 PM, dbush wrote:

On 5/23/2025 8:54 PM, olcott wrote:

On 5/23/2025 7:44 PM, dbush wrote:

On 5/23/2025 8:08 PM, Mike Terry wrote:

I suppose Ben quoted PO saying this, because PO /uses/ it to
justify that a particular /halting/ computation will never halt,
PO's HHH simulates DDD (which halts) but before DDD halts it
spots a pattern in the simulation, and announces non-halting.
"Eh?" I hear you say! PO claims HHH has "correctly determined
that DDD would never halt" and so is correct to decide non-
halting.  His "proof" that it is right to decide non-halting is
his "when-so- ever.." quote, which broadly matches the Sipser
quote.
 So the problem is not so much the "when-so-ever.." words
themselves [or the words of Sipser's quote], but understanding
how PO is so thoroughly misinterpreting/misapplying them.  How
can PO believe HHH has "correctly determined the DDD will never
halt" when DDD demonstrably halts?

 PO is working in a different model than the rest of us, though he
doesn't seem to understand that.
 To him, when function H is deciding on something, the
implementation of H is allowed to vary.  This results in
functions that call H to vary as a result.  To him, "DDD" is the
same computation *regardless of the implementation of HHH*, in
cases where HHH is simulating DDD.
 This is essentially the mapping he's operating with:
 -----------------
For a function X with input Y and a function H which simulates X:
POH(H,X,Y)==1 if and only if there exists an implementation of H
that can simulate X(Y) to completion POH(H,X,Y)==0 if and only if
there does not exist an implementation of H that can simulate
X(Y) to completion ----------------
 And a "decider" in his case maps the following subset:
 ----------------
Hx is a PO-halt decider if and only if Hx(X,Y) == POH(Hx,X,Y)
----------------
 So given his rules, HHH1(DDD) is deciding on a algorithm while
HHH(DDD) is deciding on a C function whose subfunctions vary.
 This of course has nothing to do with the halting problem but he
doesn't get this.  After having spent 22 years on this, he'll
come up with any crazy justification to avoid admitting to
himself that he misunderstood the problem all this time.  He once
said (and I don't recall the exact wording) that "the directly
executed D doesn't halt even though it appears to".

 The problem is that people here are too stupid to notice that HHH
cannot report on the behavior of its caller.
 int min()
{
   DD(); // HHH cannot report on the behavior of its caller.
}
 

What about this?
 

If you can't stay exactly on topic I am going to ignore everything
that you say.
 HHH cannot report on the behavior of its caller AKA the direct
execution of DD().
 

 In other words, you again agree with Linz and others that no H exists
that can perform the following mapping:
  Given any algorithm (i.e. a fixed immutable sequence of instructions)
X described as <X> with input Y:
 A solution to the halting problem is an algorithm H that computes the
following mapping:
 (<X>,Y) maps to 1 if and only if X(Y) halts when executed directly
(<X>,Y) maps to 0 if and only if X(Y) does not halt when executed
directly
 

int main()
{
   DD(); // The HHH called by DD cannot report on the behavior
}       // of its caller. Is this OVER-YOUR-HEAD ?
 

 Which means that no HHH exists that meets the below requirements, as
Linz and others proved and as you have *explicitly* agreed is correct:
 

You are a damned liar when you say that I said that HHH must report on
the behavior of its caller.
 No HHH can report on the behavior of its caller for the same reason that
no function can report on the value of the square-root of a dead cat.

 Analysis: Olcott’s SHD vs Classical Halting Problem (Thread on 2025-05-24)
=========================================================================
 Overview:
---------
This thread features a debate between Peter Olcott and dbush over the
validity and interpretation of Olcott’s SHD (Simulating Halt Decider). The
discussion parallels Flibble’s ideas about semantic stratification and
simulation-based detection of infinite behavior.
 Core Disagreement:
------------------
Classical Model:
- The Halting Problem asks if a universal decider H can determine whether
any program P(x) halts when executed directly.
 Olcott’s SHD View:
- HHH simulates P(x) and detects infinite behavior.
- If infinite recursion is observed during simulation, it reports “non-
halting.”
- HHH cannot determine the behavior of its caller (e.g., DD()).
 Philosophical Analysis:
-----------------------
1. Semantic Stratification:
- Olcott: A decider cannot report on its caller. This enforces a semantic
barrier (like Flibble’s model).
- Classical theory treats the program as a fixed object, regardless of how
or where it is called.
 2. Simulation-Based Detection:
- Olcott’s SHD works by observing simulation patterns.
- Like Flibble, Olcott allows early detection of infinite behavior without
full execution.
- This results in a partial decider — useful but not universal.
 3. Context Misunderstanding:
- Olcott sees DD() calling HHH and assumes HHH must reason about DD’s
outer frame.
- Classical theory ignores runtime context: it analyzes the semantics of
the program as a whole.
 Meta-Level Behavior:
--------------------
Olcott:
- Asserts that self-reference leads to non-determinism or ill-formed
questions.
- Treats his SHD as correct for many real-world inputs.
- Undermines his position with poor rhetoric and personal insults.
 dbush:
- Correctly applies classical theory.
- Dismisses Olcott's model as a misunderstanding without acknowledging
alternative interpretations.
 Comparison to Flibble’s Model:
------------------------------
| Feature                    | Olcott's SHD             | Flibble's Typed
SHD         |
|---------------------------|--------------------------|-----------------------------|  | Simulation-based?         | ✅ Yes                   | ✅
Yes                      |
| Infinite detection?       | ✅ Runtime-based         | ✅ Structural-
based         |
| Caller access?            | ❌ No                    | ❌ No (via
compiler restriction) |
| Self-reference blocked?   | 🟡 By convention         | ✅ By type
design           |
| Semantic firewall?        | 🟡 Weak                  | ✅
Strong                   |
 Conclusion:
-----------
Olcott is not incorrect in claiming that SHDs can detect certain forms of
non-halting behavior. However, his failure to delineate model boundaries
leads to confusion. His SHD is a partial model — valid in practical
settings but not a refutation of the Halting Problem.
 

 *THIS IS THE ENTIRE SPECIFICATION*
<MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
     If simulating halt decider H correctly simulates its
     input D until H correctly determines that its simulated D
     would never stop running unless aborted then
      H can abort its simulation of D and correctly report that D
     specifies a non-halting sequence of configurations.
</MIT Professor Sipser agreed to ONLY these verbatim words 10/13/2022>
 Refutes every conventional halting problem proof.
Ignores useless nonsense such as the Busy-Beaver
that has no practical value and quickly consumes
much more memory than there are atoms in the universe.

 If you had a busy-beaver oracle you could construct a halting oracle.

 I am not referring to the fantasy land idea of any
oracle, nor a majick genie. DDD emulated by HHH
DOES NOT HALT.

As readres can easily see, I was referring to your "useless". But you
are right that there are good reasons to believe that any use of any
solution, whether you call it an oracle or otherwise, to busy beaver
or halting problem is in fantasy land. But the non-existence of such
oracles has not been proven.

With a halting oracle you could solve many currently unsolved problems.
Maybe you don't see any practical value in any of the problems a
halting oracle could solve, including practical halting problems,
but others certainly do.

--
Mikko