XPost: comp.theory, alt.messianic   
   From: user7160@newsgrouper.org.invalid   
      
   On 2/10/26 8:30 PM, Richard Damon wrote:   
   > On 2/10/26 1:13 AM, 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.   
   >   
   > You mean you are MISUSING the term that has a proper definition.   
   >   
   > As I pointed out, what you are describing isn't a "property" of the   
   > input, as it isn't dependent on just the input.   
   >   
   >>   
   >> wish u know why a definist fallacy is a fallacy   
   >   
   > But YOU just admitted that you are the one doing the definist fallacy,   
   > as YOU are the one using a biased definition, not the REAL definition of   
   > the term.   
   >   
   >>   
   >>>   
   >>> 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???   
   >   
   > Because it is a property of the PROBLEM, not the individual inputs.   
   >   
   > What is so hard to imagine that?   
      
   because a "problem" is just a function mapping of inputs to outputs in   
   accordance with some kind of desired classification. if all inputs can   
   be coherently mapped to their appropriately truthful outputs, meaning   
   all inputs are /decidable/ ... then the "problem" is /decidable/   
      
   an undecidable "problem" is just on where some inputs cannot be mapped   
   to their appropriate outputs, meaning those inputs where not decidable   
   or /undecidable/, making the "problem" /undecidable/. undecidable   
   problems are *defined* by the existence of undecidable inputs, for if   
   those undecidable inputs don't exist ... how is the "problem"   
   undecidable???   
      
   i really don't know why i needed to spell that out,   
      
   especially cause ur still gunna disagree,   
      
   fuck 🫩🫩🫩   
      
   >   
   >>   
   >> honestly richard u really are walking up ur own asshole at this point   
   >   
   > Nope, you are just showing you don't really know what you are talking   
   > about.   
   >   
   >>   
   >>> 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,   
   >>>>    }   
   >>>>   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)