XPost: comp.theory, sci.logic   
   From: polcott333@gmail.com   
      
   On 7/21/2025 9:20 PM, Richard Damon wrote:   
   > On 7/21/25 9:45 AM, olcott wrote:   
   >> On 7/21/2025 4:06 AM, Mikko wrote:   
   >>> On 2025-07-20 11:48:37 +0000, Mr Flibble said:   
   >>>   
   >>>> On Sun, 20 Jul 2025 07:13:43 -0400, Richard Damon wrote:   
   >>>>   
   >>>>> On 7/20/25 12:58 AM, olcott wrote:   
   >>>>>> 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.   
   >>>>>>   
   >>>>> Your problem is you don't understand the meaning of the words you are   
   >>>>> using.   
   >>>>   
   >>>> This is an ad hominem attack, not argumentation.   
   >>>   
   >>> It is also honest and truthful, which is not as common as it should.   
   >>>   
   >>   
   >> It is also honest and truthful that people   
   >> that deny verified facts are either liars   
   >> or lack sufficient technical competence.   
   >>   
   >   
   > Right, so YOU are the liar.   
   >   
   > It is a verified fact that the PROGRAM DDD halts since your HHH(DDD)   
   > returns 0.   
   >   
      
   It is a self-evident truth that the halting problem proof   
   has always been incorrect when it requires a halt decider   
   to report on the behavior of the direct execution of any   
   Turing machine because no Turing machine decider can ever   
   take another directly executed Turing machine as its input.   
      
   The presumption that the behavior specified by the machine   
   description of a machine is always exactly the same as the   
   behavior of the directly executed machine has one exception.   
      
   When the input to the decider calls its own simulating halt   
   decider this causes recursive simulation. This changes the   
   behavior. The direct execution halts and the correctly simulated   
   machine cannot possibly halt.   
      
   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.∞   
       ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H reaches   
       its simulated final halt state of ⟨Ĥ.qn⟩, and   
      
   Ĥ.q0 ⟨Ĥ⟩ ⊢* Ĥ.embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn   
       ⟨Ĥ⟩ ⟨Ĥ⟩ simulated by Ĥ.embedded_H cannot possibly   
       reach its simulated final halt state of ⟨Ĥ.qn⟩.   
      
   When Ĥ is applied to ⟨Ĥ⟩ and embedded_H is a simulating   
   partial halt decider   
   (a) Ĥ copies its input ⟨Ĥ⟩   
   (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩   
   (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩   
   (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩   
   (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩   
   (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ ...   
      
   Because ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H   
   would remain stuck in recursive simulation unless   
   embedded_H aborts this simulation embedded_H is   
   correct to transition to its own final state of Ĥ.qn.   
      
   --   
   Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius   
   hits a target no one else can see." Arthur Schopenhauer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)