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,455 of 262,912    |
|    Richard Damon to olcott    |
|    Re: The Halting Problem asks for too muc    |
|    10 Jan 26 21:34:41    |
   
   XPost: comp.theory, sci.math, comp.lang.prolog   
   XPost: comp.software-eng   
   From: news.x.richarddamon@xoxy.net   
      
   On 1/10/26 9:22 PM, olcott wrote:   
   > 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"?   
   >>   
   >   
      
   [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