From: fedora@fea.st   
      
   On Mon, 9 Feb 2026 22:13:23 -0800, dart200   
    wrote:   
      
   >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   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)