Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem

On 5/11/2025 11:56 AM, olcott wrote:

On 5/11/2025 10:49 AM, Mr Flibble wrote:

On Sun, 11 May 2025 16:47:09 +0100, Richard Heathfield wrote:
>

On 11/05/2025 16:34, Mr Flibble wrote:

On Sun, 11 May 2025 16:25:14 +0100, Richard Heathfield wrote:
>

For a question to be semantically incorrect, it takes more than just
you and your allies to be unhappy with it.

>
For a question to be semantically correct, it takes more than just you
and your allies to be happy with it.

>
Indeed. It has to have meaning. It does. That meaning has to be
understood by sufficiently intelligent people. It is.
>
You don't like the question. I get that. I don't know /why/ you don't
like it, because all your explanations to date have been complete
expletive deleted. For a Usenet article to be semantically correct, it
helps if your readers can understand what the <exp. del.> you're talking
about.
>
What I get from your stand is that you agree with olcott that a
'pathological' input halts... no, never halts... well, you can't decide
between you, but you're agreed that it's definitely decidable, right?

>
Re-read the OP for my answer:
>
Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in
the Halting Problem
===========================================================================================
>
Summary
-------
Flibble argues that the Halting Problem's undecidability proof is built on
a category (type) error: it assumes a program and its own representation
(as a finite string) are interchangeable. This assumption fails under
simulating deciders, revealing a type distinction through behavioral
divergence. As such, all deciders must respect this boundary, and
diagonalization becomes ill-formed. This reframing dissolves the paradox
by making the Halting Problem itself an ill-posed question.
>
1. Operational Evidence of Type Distinction
-------------------------------------------
- When a program (e.g., `DD()`) is passed to a simulating halt decider
(`HHH`), it leads to infinite recursion.
- This behavior differs from direct execution (e.g., a crash due to a
stack overflow).

 The directly executed DD() simply halts because

It performs a series of steps that result in DD reaching a final state.
What those steps are is irrelevant with regard to halt status.

DD emulated by HHH according to the rules of the
x86 language

Does not happen, as you have admitted on the record:
On 5/5/2025 8:24 AM, dbush wrote:
 > On 5/4/2025 11:03 PM, dbush wrote:
 >> On 5/4/2025 10:05 PM, olcott wrote:
 >>> On 5/4/2025 7:23 PM, Richard Damon wrote:
 >>>> But HHH doesn't correct emulated DD by those rules, as those rules
 >>>> do not allow HHH to stop its emulation,
 >>>
 >>> Sure they do you freaking moron...
 >>
 >> Then show where in the Intel instruction manual that the execution of
 >> any instruction other than a HLT is allowed to stop instead of
 >> executing the next instruction.
 >>
 >> Failure to do so in your next reply, or within one hour of your next
 >> post on this newsgroup, will be taken as you official on-the-record
 >> admission that there is no such allowance and that HHH does NOT
 >> correctly simulate DD.
 >
 > Let the record show that Peter Olcott made the following post in this
 > newsgroup after the above message:
 >
 > On 5/4/2025 11:04 PM, olcott wrote:
 >  > D *WOULD NEVER STOP RUNNING UNLESS*
 >  > indicates that professor Sipser was agreeing
 >  > to hypotheticals AS *NOT CHANGING THE INPUT*
 >  >
 >  > You are taking
 >  > *WOULD NEVER STOP RUNNING UNLESS*
 >  > to mean *NEVER STOPS RUNNING* that is incorrect.
 >
 > And has made no attempt after over 9 hours to show where in the Intel
 > instruction manual that execution is allowed to stop after any
 > instruction other than HLT.
 >
 > Therefore, as per the above criteria:
 >
 > LET THE RECORD SHOW
 >
 > That Peter Olcott
 >
 > Has *officially* admitted
 >
 > That DD is NOT correctly simulated by HHH