• Re: Title: A Structural Analysis of the Standard Halting Problem Proof

    From Mild Shock@21:1/5 to olcott on Wed Jul 23 15:34:53 2025
    You bisimilarity is broken

    It shows halting not as a decidable property.
    If you have M1 ~ M2, and M2 is still not decidable
    but has the same notion of termination nevertheless,

    means logically you didn't really make any error,
    only you showed nothing. Not much was gained.

    I guess you need to start all over agan.

    olcott schrieb:
    Title: A Structural Analysis of the Standard Halting Problem Proof

    Author: PL Olcott

    Abstract:
    This paper presents a formal critique of the standard proof of the undecidability of the Halting Problem. While we do not dispute the
    conclusion that the Halting Problem is undecidable, we argue that the conventional proof fails to establish this conclusion due to a
    fundamental misapplication of Turing machine semantics. Specifically, we
    show that the contradiction used in the proof arises from conflating the behavior of encoded simulations with direct execution, and from making assumptions about a decider's domain that do not hold under a rigorous
    model of computation.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mikko@21:1/5 to olcott on Sun Jul 27 10:52:52 2025
    On 2025-07-26 14:02:15 +0000, olcott said:

    On 7/26/2025 6:14 AM, Richard the Demon wrote:
    On 7/25/25 9:29 PM, olcott wrote:
    On 7/25/2025 8:22 PM, Richard the Demon wrote:
    On 7/25/25 7:42 PM, olcott wrote: >>>>
    _DDD()
    [00002192] 55         push ebp
    [00002193] 8bec       mov ebp,esp
    [00002195] 6892210000 push 00002192  // push DDD
    [0000219a] e833f4ffff call 000015d2  // call HHH
    [0000219f] 83c404     add esp,+04
    [000021a2] 5d         pop ebp
    [000021a3] c3         ret
    Size in bytes:(0018) [000021a3]

    Until you provide the execution trace of DDD emulated
    by HHH (according to the rules of the x86 language)
    such that this emulated DDD reaches its own emulated
    "ret" instruction final halt state
    *you will be considered a fucking liar*


    That is just a lIE.

    Until you realize that HHH just doesn't do a correct simulation,
    *You dishonestly changed the words that I said, as you always do*
    *Here are the words that I actually said*
    (according to the rules of the x86 language)


    Because your HHH ignores the last step of the last instruction it
    processes, that of execute the next instruction.


    <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

    _DDD()
    [00002192] 55 push ebp
    [00002193] 8bec mov ebp,esp
    [00002195] 6892210000 push 00002192 // push DDD
    [0000219a] e833f4ffff call 000015d2 // call HHH
    [0000219f] 83c404 add esp,+04
    [000021a2] 5d pop ebp
    [000021a3] c3 ret
    Size in bytes:(0018) [000021a3]

    As soon as HHH emulates DDD then emulates itself
    emulating DDD and this DDD calls HHH(DDD) to do it
    again, HHH has matched a non-terminating behavior pattern.

    That is false. The behavour of DDD is that it terminates.
    Therefore no pattern it matches is a non-terminating pattern.

    --
    Mikko

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