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,453 of 262,912   
   olcott to Richard Damon   
   Re: The Halting Problem asks for too muc   
   10 Jan 26 20:22:27   
   
   XPost: comp.theory, sci.math, comp.lang.prolog   
   XPost: comp.software-eng   
   From: polcott333@gmail.com   
      
   On 1/10/2026 8:03 PM, Richard Damon wrote:   
   > On 1/10/26 7:52 PM, olcott wrote:   
   >> On 1/10/2026 6:35 PM, Richard Damon wrote:   
   >>> 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.   
   >>>   
   >>   
   >> Every explanation of the problem requires a result that   
   >> cannot be derived by applying finite string transformation   
   >> rules to actual finite string inputs.   
   >   
   > LIE!!!   
   >   
   > Whys isn't [DD] -> Halting a "Finite String Transformation"?   
   >   
      
   Finite String Transformations of   
   INPUT FINITE STRINGS   
   INPUT FINITE STRINGS   
   INPUT FINITE STRINGS   
   INPUT FINITE STRINGS   
   INPUT FINITE STRINGS   
      
      
   [continued in next message]   
      
   --- 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