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,449 of 262,912    |
|    olcott to Richard Damon    |
|    Re: The Halting Problem asks for too muc    |
|    10 Jan 26 18:52:47    |
   
   XPost: comp.theory, sci.math, comp.lang.prolog   
   XPost: comp.software-eng   
   From: polcott333@gmail.com   
      
   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.   
      
   When an input does the opposite of whatever value   
   its decider returns: Does this input halt?   
   Is a yes/no question lacking a correct yes/no answer   
   thus an incorrect question.   
      
   > 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.   
      
      
   --   
      
   [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