XPost: comp.theory, alt.messianic   
   From: user7160@newsgrouper.org.invalid   
      
   On 2/7/26 7:49 PM, Richard Damon wrote:   
   > On 2/7/26 6:52 PM, dart200 wrote:   
   >> On 2/7/26 1:09 PM, dart200 wrote:   
   >>> On 2/7/26 6:34 AM, Richard Damon wrote:   
   >>>> On 2/7/26 1:06 AM, dart200 wrote:   
   >>>>> On 2/6/26 7:55 PM, Richard Damon wrote:   
   >>>>>   
   >>>>> an input can be (P OR !P) in regards to actual property and   
   >>>>> independently it can be (DECIDABLE OR UNDECIDABLE) in regards to   
   >>>>> whether it contradicts the classifiers return value, so from the   
   >>>>> perspective of a particular partial recognizer call the input can   
   >>>>> be one of 4 permutations:   
   >>>>>   
   >>>>> P AND DECIDABLE     - return TRUE   
   >>>>> P AND UNDECIDABLE   - return FALSE   
   >>>>> !P AND DECIDABLE    - return FALSE   
   >>>>> !P AND UNDECIDABLE  - return FALSE   
   >>>>>   
   >>>>> there's no "other" category an input can be in regards to a   
   >>>>> particular classifier call. to suggest otherwise is to violate the   
   >>>>> law of excluded middle   
   >>>>   
   >>>> In other words, your machine just isn't even a partial decider for   
   >>>> the halting problem, and based on a category error with the term   
   >>>> DECIDABLE.   
   >>>   
   >>> i've explained what i mean by UNDECIDABLE here, calling me wrong   
   >>> because not i'm using the word in exactly the same was as u'd like is   
   >>> 100% a definist fallacy. why?   
   >>>   
   >>> cause it's not addressing the underlying idea, ur just attacking the   
   >>> syntax and that's just shallow   
   >>>   
   >>>>   
   >>>> Since you seem to mean that "Decidable" means "I will get this right"   
   >>>   
   >>> not *will*, but *able to*   
   >>>   
   >>> return FALSE when the input has P and is DECIDABLE is violating the   
   >>> contract moron   
   >>>   
   >>>> and "Undecidable" means "I will not get this right", a TRIVIAL   
   >>>> implementation is to just return FALSE.   
   >>   
   >> see, while a partial recognizer does not guarantee returning TRUE for   
   >> all machines with P, there is no flexibility in what machines it does   
   >> return TRUE for:   
   >>   
   >> all machines that have P   
   >>    AND are DECIDABLE input   
   >   
   > MISUSE of the TERM.   
      
   DEFINIST FALLACY   
      
   >   
   > There are no "Decidable Inputs" only "Decidable problems".   
      
   a "decidable problem" is just one where all inputs are DECIDABLE.   
      
   yes, that is an additional way to use the word, but because   
   "un/decidable inputs" and "un/decidable problem" are intimately related   
   i see fit to use them that way. u can disagree with my word choice, but   
   calling me wrong over my word choice is a classic DEFINIST FALLACY. that   
   you must be really comfortable with using.   
      
   >   
   > The closest thing to an "undecidable input" is an input whose answer   
   > turns out to be unknowable in the system, and for halting, such input   
   > can not be detected as such, as determining that actually decides them   
   > (since the only unknowable inputs are non-halting).   
      
   unfortunately this is a mistaken understanding of the nature of   
   decidability. an input can be decidable to one classifier while being   
   undecidable to another classifer.   
      
   one CAN create a halting machine that is still an UNDECIDABLE input in   
   regards to some other semantic property P, i sketched out such a program   
   several times now.   
      
   here's another in regards to whether an input machine executes an add   
   operation or not:   
      
      adds = (machine) -> {   
        TRUE if machine performs an add computation   
          AND machine is a DECIDABLE input,   
        FALSE if machine does not perform an add computation   
          OR machine is an UNDECIDABLE input,   
      }   
      
      und_add = () -> {   
        if ( adds(und_add) == FALSE)   
          print 1+1   
        else   
          print 0   
      }   
      
   adds(und_add)->FALSE, because und_add is not a DECIDABLE input to   
   adds(), so therefore adds cannot return the truth that it does execute   
   an integer add operation. however, this is quite clearly a halting   
   function, and halts() is entirely able to return: halts(und_add)->TRUE   
      
   >   
   >>   
   >> the supposed "trivial" implementation does not suffice to fulfill this   
   >> contract bro   
   >>   
   >   
   > Sure it does.   
   >   
   > Since Halting is "Undecidable" returning false is always correct.   
      
   it's pretty mind blowing you u think just willfully ignoring my   
   specification and call it a refutation   
      
   >   
   > If you mean that the decider will get the answer wrong, then FALSE is   
   > also always correct.   
   >   
   > If the input is halting, then returning false is incorrect for the base   
   > decision of halting, and thus is correct for you expanded critera, as   
   > its answer is wrong for the basic criteria, and thus is "UNDECIADBLE"   
   > for this decider.   
   >   
   > How is that not a correct answer?   
      
      
   --   
   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)