XPost: comp.theory, alt.messianic   
   From: user7160@newsgrouper.org.invalid   
      
   On 2/6/26 7:55 PM, Richard Damon wrote:   
   > On 2/6/26 9:36 PM, dart200 wrote:   
   >> my proposal starts with the reminder that *no* machine computes a   
   >> unique function. for every function that is computed, there is a whole   
   >> (infinite) class of machines that are functionally equivalent (same   
   >> input -> same output behavior).   
   >   
   > Fine   
   >   
   >>   
   >> we should then consider a working thesis: no paradoxical machine is   
   >> the simplest of their class of functionally equivalent machines.   
   >   
   > Something you would need to PROVE.   
   >   
   > And, something of not particular value since determining the equivalence   
   > class of a given machine is non-computable.   
   >   
   >>   
   >> why? the paradox structures do not actually contribute to the output   
   >> (since deciders themselves do not create output for the “calling”   
   >> machine), they are just sort of junk computation that selects a   
   >> particular execution branch (or blocks entirely), a result which can   
   >> exist without that paradox fluff being involved.   
   >   
   > Not really a proof, but a presumption.   
   >   
   > And remember, the "output" of the "paradoxical" machine includes its   
   > possible deciding to not halt.   
   >   
   > And again, it doesn't help you answer the actual question.   
   >   
   >>   
   >> consider the basic paradox form:   
   >>   
   >>    deciderP(input) - decides if input has property P or !P   
   >>    machineP()      - machine that has property P   
   >>    machine!P()     - machine that has property !P   
   >>   
   >>    // undecidable by deciderP for property P   
   >>    undP = () -> {   
   >>      if ( deciderP(undP) == TRUE )   
   >>        machine!P()   
   >>      else   
   >>        machineP()   
   >>    }   
   >>   
   >> huh, i guess i kinda get why this wasn’t really spotted before. as far   
   >> as i can tell, classical computing theory normally recognizes three   
   >> kinds of classifiers:   
   >>   
   >>   
   >>    classical decider:   
   >>      TRUE iff input has P   
   >>      FALSE iff input has !P (always DECIDABLE)   
   >>      impossible interface   
   >>   
   >>    classical recognizer:   
   >>      TRUE iff input has P (always DECIDABLE)   
   >>      FALSE iff input has !P (block if UNDECIDABLE)   
   >   
   > Not "UNDECIDABLE", but *I* Couldn't decide.   
      
   yes, i'm aware that undecidability is *always* in respect to particular   
   inputs for particular interfaces, as for any true classifier one can   
   construct input that it can decide on   
      
   >   
   >>   
   >>    partial decider:   
   >>      TRUE iff input has P   
   >>      FALSE iff input has !P   
   >>      (block if either UNDECIDABLE)   
   >   
   > Again, not "UNDECIDABLE", but *I* couldn't decide.   
      
   yes that's what the return value means, the input was UNDECIDABLE in   
   respect to the classifier being asked the question   
      
   > Also, not iff, just if I was able to decide it had.   
      
   lol, that is like the ONE useful comment in ur entire post here. i   
   honestly went back and made that more precise for whereever i post this   
   next. i guess that's worth digging thru ur endless gishgallop  👌😂🔫👌   
      
   >   
   > As, for a proper question, all inputs either have P or !P   
   >   
   > (Like all machines Halt or do not halt, there is no other possibility)   
   >   
   >>   
   >> ... so the paradoxes (involving either a classical recognizer or   
   >> partial decider) always result in a blocking, non-returning program   
   >> making this thesis still valid, but less interesting/compelling.   
   >   
   > Right, PARTIAL halt deciders are know to be able to be made, so not even   
   > "less-interesting" but not interesting unless you can show that you can   
   > answer a comparative reasonable amount of answers.   
   >   
   > Just another method, without comparing to the existing, just isn't   
   > interesting at all.   
   >   
   >>   
   >> i have instead been working on the logical interface for alternative   
   >> classifiers. one example are the context-aware classifiers i’ve been   
   >> previously posting quite a bit on, but let’s consider a less general   
   >> classifier that might exist on TMs alone, what i’m calling a partial   
   >> recognizer:   
   >   
   > But the problem is that such things end up not being "Computation" and   
   > thus outside of the field.   
      
   begging the ct-thesis again   
      
   >   
   >>   
   >>    partial recognizer   
   >>      TRUE iff input has P AND is DECIDABLE   
   >>      FALSE iff input has !P OR is UNDECIDABLE   
   >   
   > Again, All inputs will either have P or !P, and your criteria isn't "is   
   > it decidable", but can I determine the answer.   
      
   yes, whether the particular input is DECIDABLE by the particular   
   classifier returning the answer   
      
   >   
   > The problem is that "Decidablity" isn't really a property of a specific   
      
   see, it's weird that you acknowledge earlier that it's that particular   
   inputs that cause UNDECIDABLE returns for particular interfaces...   
      
   but here u revert to this red herring of also being able to talk about   
   undecidability in terms of whole problems as if that "refutes" anything   
      
   > input, but of the problem as a whole. HALTING, as a problem, is   
   > undecidable, as we can create an input for ANY specific decider that it   
   > will get wrong.   
      
   sorry, what will a partial recognizer get wrong?   
      
   >   
   >>   
   >> in this case if we consider undP() from above ... deciderP(undP) would   
   >> return FALSE because undP is UNDECIDABLE by deciderP(). but that   
   >> doesn’t mean the program isn’t runnable. it certainly is, and when u   
   >> do run it, it will have the functional behavior of machineP(). which   
   >> may even halt, mind you,   
   >   
   > WHich isn't the definition of "Undeciable" as it isn't undeciable by a   
   > specific machine.   
      
   definist fallacy: it doesn't matter if we can also use the term to   
   describe problems ... we can also use it to describe the problem in   
   regards to specific input, because it's always specific input that cause   
   the problem for specific interfaces. as for any true classifier one can   
   define a surely decidable result.   
      
   >   
   >>   
   >> ...there’s this weird notion floating around that because halting   
   >> machines are certainly enumerable, therefore it’s not possible to   
   >> create an undecidable halting machine. but that’s not actually true,   
   >> paradoxes are constructed in regards to *specific* interfaces (classes   
   >> of functionally equivalent machines), not general ability. therefore,   
   >> despite the fact we can enumerate out all halting machines, it’s still   
   >> possible to construct a halting machine that is also a paradox in   
   >> respect to some property classifier like deciderP(). anyways...   
   >   
   > Enumerable, but not effectively enumerable, or computationally enumerable.   
      
   excuse me, halting machines are effectively enumerable   
      
   and i don't like distinction. if there is no effective method to   
   enumerate something, i don't like calling it enumer-able. i get that   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)