XPost: comp.theory, alt.messianic   
   From: user7160@newsgrouper.org.invalid   
      
   On 2/9/26 4:51 AM, Richard Damon wrote:   
   > On 2/7/26 11:39 PM, dart200 wrote:   
   >> 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   
   >>   
   >   
   > Yes, exactly, BY YOU.   
   >   
   > Changing the definition to try to make you point is just a fallacy.   
      
   i'm reusing the word to describe a slightly different, but highly   
   dependent concept. please attack the semantics of the *concept* itself,   
   not the particular syntax i used to describe it.   
      
   wish u know why a definist fallacy is a fallacy   
      
   >   
   > But perhaps, that logic is beyond you,\.   
   >   
   >>>   
   >>> There are no "Decidable Inputs" only "Decidable problems".   
   >>   
   >> a "decidable problem" is just one where all inputs are DECIDABLE.   
   >   
   > Nope. There is no requirement that an undeciable problem must have an   
   > instance that can not be decided, and in fact, such a case is   
      
   if an undecidable problem does not have an undecidable input at some   
   point ... then how is the problem undecidable???   
      
   honestly richard u really are walking up ur own asshole at this point   
      
   > impossible, as for any input where we know the answer, you can always   
   > make a partial decider that gets the right answer for it, but just   
   > comparing the input to that case and returning the know answer.   
   >   
   >>   
   >> 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.   
   >>   
   >   
   > No, it is an INCORRECT way to use the word, making it just a definist   
   > fallacy.   
   >   
   > It assumes properties that are not.   
   >   
   >>>   
   >>> 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.   
   >   
   > Which makes it no longer a property of the input, and thus not something   
   > that CAN be computable from the input.   
   >   
   >>   
   >> 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.   
   >   
   > No, you sketched out frameworks based on computing uncomputable properties.   
   >   
   >>   
   >> 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 problem is that und_add isn't a program, as it calls a non-function   
   > adds, that isn't a program because it doesn't define HOW it gets its   
   > answer.   
      
   my fucking god can u be less of a pissant?   
      
   >   
   > EVERY actual implementation of adds taht does meet your specification   
   > (and thus returns an answer) creates an und_add() that has a definite   
   > value of what your "adds" property claims to compute, and thus, the   
   > input itself isn't "undecidable", just incorrectly decided by that adds.   
      
   it's not "incorrect" classification, as FALSE does not indicate a   
   specific classification   
      
   it's just not classified. it's a failure to classify, because the input   
   is UNDECIDABLE in regards to adds   
      
   >   
   > If that is your definition of "Undecidable" the always returning false   
      
   i have already explain why that's not a solution to a partial recognizer   
   multiple times already u dope   
      
   > is a trivial correct solution, as either the input DOES NOT have that   
   > property, and thus false is the correct answer, or the input DOES have   
   > that property, and thus this decider will be wrong by the base   
   > definition of the property, and thus correct because it was   
   > "Undecidable" to it.   
   >   
   >>   
   >>>   
   >>>>   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)