XPost: comp.theory, comp.software-eng   
   From: user7160@newsgrouper.org.invalid   
      
   On 1/6/26 8:33 PM, olcott wrote:   
   > On 1/6/2026 9:03 PM, dart200 wrote:   
   >> On 1/6/26 5:26 PM, olcott wrote:   
   >>> On 1/6/2026 1:47 AM, dart200 wrote:   
   >>>> On 1/5/26 4:24 PM, Oleksiy Gapotchenko wrote:   
   >>>>> Just an external observation:   
   >>>>>   
   >>>>> A lot of tech innovations in software optimization area get   
   >>>>> discarded from the very beginning because people who work on them   
   >>>>> perceive the halting problem as a dogma. As result, certain   
   >>>>> practical things (in code analysis) are not even tried because it's   
   >>>>> assumed that they are bound by the halting problem.   
   >>>>>   
   >>>>> In practice, however, the halting problem is rarely a limitation.   
   >>>>> And even when one hits it, they can safely discard a particular   
   >>>>> analysis branch by marking it as inconclusive.   
   >>>>>   
   >>>>> Halting problem for sure can be better framed to not sound as a   
   >>>>> dogma, at least. In practice, algorithmic inconclusiveness has   
   >>>>> 0.001 probability, not a 100% guarantee as many engineers perceive it.   
   >>>>   
   >>>> god it's been such a mind-fuck to unpack the halting problem,   
   >>>>   
   >>>> but the halting problem does not mean that no algorithm exists for   
   >>>> any given machine, just that a "general" decider does not exist for   
   >>>> all machiens ...   
   >>>>   
   >>>> heck it must be certain that for any given machine there must exist   
   >>>> a partial decider that can decide on it ... because otherwise a   
   >>>> paradox would have to address all possible partial deciders in a   
   >>>> computable fashion and that runs up against it's own limit to   
   >>>> classical computing. therefore some true decider must exist for any   
   >>>> given machine that exists ... we just can't funnel the knowledge   
   >>>> thru a general interface.   
   >>>>   
   >>>   
   >>> For every H there is a D such that D does the opposite   
   >>> of whatever H reports. In this case use H1 on this D.   
   >>   
   >> yes, the inability to correctly resolve halting thru a singular   
   >> interface is a flaw of TM computing, not an inherent algorithmic limit   
   >>   
   >   
   > No it is not that.   
   > After spending 20,000 hours on this over 20 years   
   > equivalent to ten full time years.   
   >   
   > *if undecidability is correct then truth itself is broken*   
   > *if undecidability is correct then truth itself is broken*   
   > *if undecidability is correct then truth itself is broken*   
   > *if undecidability is correct then truth itself is broken*   
   >   
   > The simplest 100% correct resolution to the   
   > actual definition of the Halting Problem   
   > (that includes the counter-example input)   
   > Is that (in the case of the counter-example input)   
   > The halting problem asks a yes/no question   
   > that has no correct yes/no answer.   
      
   i love how you agree with the consensus position but think u don't   
      
   >   
   > *The HP asks an incorrect question*   
   > *The HP asks an incorrect question*   
   > *The HP asks an incorrect question*   
   > *The HP asks an incorrect question*   
   >   
   > We can only get to your idea of a different   
   > interface when we change the definition of   
   > that Halting Problem. The original problem   
   > itself is simply incorrect.   
      
   the question's a fine expectation   
      
   TMs can't represent the answer tho, and that's the real problem   
      
   >   
   > *I proved the HP input is the same as the Liar Paradox back in 2004*   
   > *I proved the HP input is the same as the Liar Paradox back in 2004*   
   > *I proved the HP input is the same as the Liar Paradox back in 2004*   
   > *I proved the HP input is the same as the Liar Paradox back in 2004*   
   >   
   > function LoopIfYouSayItHalts (bool YouSayItHalts):   
   >    if YouSayItHalts () then   
   >      while true do {}   
   >    else   
   >      return false;   
   >   
   > Does this program Halt?   
   >   
   > (Your (YES or NO) answer is to be considered   
   >   translated to Boolean as the function's input   
   >   parameter)   
   >   
   > Please ONLY PROVIDE CORRECT ANSWERS!   
   >   
   > https://groups.google.com/g/sci.logic/c/Hs78nMN6QZE/m/ID2rxwo__yQJ   
   >   
   >   
      
      
   --   
   arising us out of the computing dark ages,   
   please excuse my pseudo-pyscript,   
   ~ nick   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)