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

On 5/11/2025 10:39 PM, olcott wrote:

On 5/11/2025 9:34 PM, dbush wrote:

On 5/11/2025 10:30 PM, olcott wrote:

On 5/11/2025 9:23 PM, Richard Heathfield wrote:

On 12/05/2025 03:05, olcott wrote:

On 5/11/2025 8:34 PM, Richard Heathfield wrote:

On 12/05/2025 02:12, olcott wrote:
>
<snip>
>

No one here is using any actual reasoning
in their rebuttals of my work.

>
I have already shown several places where your 'work' violates the rules of its implementation's language standard,

>
My compiler disagrees so I can't fix that.

>
C compilers are obliged to diagnose syntax errors. If they don't, they're not-quite-C compilers. You need to decide whether you're writing in C or whether you're not.
>

>
>
_DDD()
[00002172] 55         push ebp      ; housekeeping
[00002173] 8bec       mov  ebp,esp  ; housekeeping
[00002175] 6872210000 push 00002172 ; push DDD
[0000217a] e853f4ffff call 000015d2 ; call HHH(DDD)
[0000217f] 83c404     add  esp,+04
[00002182] 5d         pop  ebp
[00002183] c3         ret
Size in bytes:(0018) [00002183]
>
When testing the proof-of-concept not one line
of my code is relevant. The only thing that needs
be determined is the behavior of DDD under some
HHH

>
Category error.  Algorithm DDD isn't fully defined until algorithm HHH is fully defined.
>
So yes the code is relevant.

 Algorithm HHH is fully defined as an x86 emulator
that emulates one or more steps of DDD according
to the rules of the x86 language.

Which means "some HHH" is a category error.  There is only one algorithm HHH and one algorithm DDD.
And it doesn't emulate DDD according to the rules of the x86 language 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