home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   sci.logic      Logic -- math, philosophy & computationa      262,912 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 262,448 of 262,912   
   Richard Damon to olcott   
   Re: The Halting Problem asks for too muc   
   10 Jan 26 19:35:31   
   
   XPost: comp.theory, sci.math, comp.lang.prolog   
   XPost: comp.software-eng   
   From: news.x.richarddamon@xoxy.net   
      
   On 1/10/26 7:13 PM, olcott wrote:   
   > On 1/10/2026 5:19 PM, Richard Damon wrote:   
   >> On 1/10/26 10:47 AM, olcott wrote:   
   >>> On 1/10/2026 2:23 AM, Mikko wrote:   
   >>>> On 09/01/2026 17:52, olcott wrote:   
   >>>>> On 1/9/2026 3:59 AM, Mikko wrote:   
   >>>>>> On 08/01/2026 16:22, olcott wrote:   
   >>>>>>> On 1/8/2026 4:22 AM, Mikko wrote:   
   >>>>>>>> On 07/01/2026 13:54, olcott wrote:   
   >>>>>>>>> On 1/7/2026 5:49 AM, Mikko wrote:   
   >>>>>>>>>> On 07/01/2026 06:44, olcott wrote:   
   >>>>>>>>>>> All deciders essentially: Transform finite string   
   >>>>>>>>>>> inputs by finite string transformation rules into   
   >>>>>>>>>>> {Accept, Reject} values.   
   >>>>>>>>>>>   
   >>>>>>>>>>> The counter-example input to requires more than   
   >>>>>>>>>>> can be derived from finite string transformation   
   >>>>>>>>>>> rules applied to this specific input thus the   
   >>>>>>>>>>> Halting Problem requires too much.   
   >>>>>>>>>   
   >>>>>>>>>> In a sense the halting problem asks too much: the problem is   
   >>>>>>>>>> proven to   
   >>>>>>>>>> be unsolvable. In another sense it asks too little: usually we   
   >>>>>>>>>> want to   
   >>>>>>>>>> know whether a method halts on every input, not just one.   
   >>>>>>>>>>   
   >>>>>>>>>> Although the halting problem is unsolvable, there are partial   
   >>>>>>>>>> solutions   
   >>>>>>>>>> to the halting problem. In particular, every counter-example   
   >>>>>>>>>> to the   
   >>>>>>>>>> full solution is correctly solved by some partial deciders.   
   >>>>>>>>>   
   >>>>>>>>> *if undecidability is correct then truth itself is broken*   
   >>>>>>>>   
   >>>>>>>> Depends on whether the word "truth" is interpeted in the standard   
   >>>>>>>> sense or in Olcott's sense.   
   >>>>>>>   
   >>>>>>> Undecidability is misconception. Self-contradictory   
   >>>>>>> expressions are correctly rejected as semantically   
   >>>>>>> incoherent thus form no undecidability or incompleteness.   
   >>>>>>   
   >>>>>> The misconception is yours. No expression in the language of the   
   >>>>>> first   
   >>>>>> order group theory is self-contradictory. But the first order goupr   
   >>>>>> theory is incomplete: it is impossible to prove that AB = BA is true   
   >>>>>> for every A and every B but it is also impossible to prove that AB   
   >>>>>> = BA   
   >>>>>> is false for some A and some B.   
   >>>>>>   
   >>>>>   
   >>>>> All deciders essentially: Transform finite string   
   >>>>> inputs by finite string transformation rules into   
   >>>>> {Accept, Reject} values.   
   >>>>>   
   >>>>> When a required result cannot be derived by applying   
   >>>>> finite string transformation rules to actual finite   
   >>>>> string inputs, then the required result exceeds the   
   >>>>> scope of computation and must be rejected as an   
   >>>>> incorrect requirement.   
   >>>>   
   >>>> No, that does not follow. If a required result cannot be derived by   
   >>>> appying a finite string transformation then the it it is uncomputable.   
   >>>   
   >>> Right. Outside the scope of computation. Requiring anything   
   >>> outside the scope of computation is an incorrect requirement.   
   >>>   
   >>>> Of course, it one can prove that the required result is not computable   
   >>>> then that helps to avoid wasting effort to try the impossible. The   
   >>>> situation is worse if it is not known that the required result is not   
   >>>> computable.   
   >>>>   
   >>>> That something is not computable does not mean that there is anyting   
   >>>> "incorrect" in the requirement.   
   >>>   
   >>> Yes it certainly does. Requiring the impossible is always an error.   
   >>> Requiring an answer to a yes/no question that has no correct yes/no   
   >>> answer is an incorrect question that must be rejected.   
   >>   
   >> But then, insisting that things are possilbe to ask the question is an   
   >> error, as you might not be able to know if it is possible when you ask   
   >> the question.   
   >>   
   >> Thus, your logic only allows that asking of questions you already know   
   >> that an answer exists.   
   >>   
   >>>   
   >>>> In order to claim that a requirement   
   >>>> is incorrect one must at least prove that the requirement does not   
   >>>> serve its intended purpose.   
   >>>   
   >>> Requiring the impossible cannot possibly serve any purpose   
   >>> except perhaps to exemplify one's own ignorance.   
   >>   
   >> But asking if it is possible lets you know about the limits of what   
   >> you can do.   
   >>   
   >> Remember, the halting problems as the question about IS IT POSSIBLE,   
   >> and that has an answer, it is not possible to to it.   
   >>   
   >   
   > Is it possible to correctly answer self-contradictory questions?   
      
   But the actual question isn't "self-contradictiory".   
      
   > No not even when they are rearranged into a Halting Problem.   
      
   But the actual problem isn't the one you talk about, only your   
   subjective misquoting of it.   
      
   >   
   > I proved the HP input is the same as the Liar Paradox back in 2004   
      
   No, that provees you don't know what the halting problem IS.,   
      
   >   
   > 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   
   > When you yourself say YES you are wrong   
   > When you yourself say NO you are wrong   
      
   But you are asking TWO questions, as the behavior of a program is a   
   funcgtion of its input.   
      
   Thus, you show you don't understand that problem.   
      
   >   
   > Therefore the halting problem counter example input   
   > is a yes/no question lacking a correct yes/no answer.   
   >   
      
      
   No, you are just showing you re too stupid to read the simple   
   explanatins of the problem.   
      
   Your problem HAS an answer, but one you reject as you don't understand   
   the question.   
      
   The correct answer is:   
   LoopIfYouSayItHalts(true) does not halt   
   LoopIfYouSayItHalts(false) halts.   
      
   Remember, the question is about the behavior of the program with its   
   input, and thus you are allowed a different answer for every possible input.   
      
   Now, for a Termination analyzer, the answer is that the program is NOT a   
   complete function, as it doens't halt for some inputs.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca