XPost: comp.theory   
   From: polcott333@gmail.com   
      
   On 10/28/2025 9:19 PM, Kaz Kylheku wrote:   
   > On 2025-10-29, olcott  wrote:   
   >> On 10/28/2025 7:25 PM, Kaz Kylheku wrote:   
   >>> Under your system, I don't know whether Y is correct.   
   >>>   
   >>> Y could be a broken decider that is wrongly deciding D (and /that/   
   >>> is why its execution trace differs from X).   
   >>>   
   >>> Or it could be the case that D is a non-input to Y, in which case Y is   
   >>> deemed to be correct because D being a non-input to Y means that D   
   >>> denotes non-halting semantics to Y (and /that/ is why its execution   
   >>> trace differs from X).   
   >>>   
   >>> The fact that the execution trace differs doesn't inform.   
   >>>   
   >>> We need to know the value of is_input(Y, D): we need to /decide/ whether   
   >>> D is non-input or input to Y in order to /decide/ whether its rejection   
   >>> is correct.   
   >>>   
   >>   
   >> Whatever is a correct simulation of an input by   
   >> a decider is the behavior that must be reported on.   
   >   
   > But under your system, if I am a user of deciders, and have been   
   > given a decider H which is certified to be correct, I cannot   
   > rely on it to decide halting.   
   >   
      
   When halting is defined correctly:   
   Does this input specify a sequence of moves that   
   reach a final halt state?   
      
   and not defined incorrectly: to require something   
   that is not specified in the input then this does   
   overcome the halting problem proof and shows that   
   the halting problem itself has always been a category   
   error. (Flibble's brilliant term).   
      
   > I want to know whether D halts, that's all.   
   >   
   > H says no. It is certified correct under your paradigm, so   
   > so I don't have to suspect that if it is given an /input/   
   > it will be wrong.   
   >   
   > But: I have no idea whether D is an input to H or a non-input!   
   >   
      
   That is ridiculous. If it is an argument   
   to the decider function then it is an input.   
      
   > When H says 0, I have no idea whether it's being judged non-halting   
   > as an input, or whether it's being judged as a non-input (whereby   
   > either value is the correct answer as far as H is concerned).   
   >   
      
   Judging by anything besides and input has always   
   been incorrect. H(D) maps its input to a reject   
   value on the basis of the behavior that this   
   argument to H specifies.   
      
   > Again, I just want to know, does D halt?   
   >   
      
   You might also want a purely mental Turing   
   machine to bake you a birthday cake.   
      
   > Under your paradigm, even though I have a certified correct H,   
   > I am not informed.   
   >   
   > Under the standard halting problem, I am not informed because   
   > I /don't/ have a certified correct H; it doesn't exist.   
   >   
      
   The standard halting problem requires behavior   
   that is out-of-scope for Turing machines, like   
   requiring that they bake birthday cakes.   
      
   > Under your paradigm, I have a deemed-correct H, which is   
   > excused for giving a garbage answer on non-inputs, which   
   > I have no way to identify.   
   >   
      
   int sum(int x, int y){return x + y;}   
   Expecting sum(3,4) to return the sum of 5 + 7 is nuts.   
   A function only computes from its arguments.   
      
   > How am I better off in your paradigm?   
   >   
      
   In my paradigm you face reality rather than   
   ignoring it.   
      
   > Do I use 10 different certified deciders, and take a majority vote?   
   >   
      
   sum(3,4) computes the sum of 3+4 even if   
   the sum of 5+6 is required from sum(3,4).   
      
   Whatever behavior is measured by the decider's   
   simulation of its input *is* the behavior that   
   it must report on.   
      
   > But the function which combines 10 deciders into a majority vote   
   > is itself a decider! And that 10-majority-decider function can be   
   > targeted by a diagonal test case ... and such a test case is now   
   > a non-input.  See?   
   >   
   >>> You are not looking at it from the perspective of a /consumer/ of a   
   >>> /decider product/ actually trying to use deciders and trust their   
   >>> answer.   
   >>   
   >> Whatever is a correct simulation of an input by   
   >> a decider is the behavior that must be reported on.   
   >   
   > But how does the user interpret that result?   
   >   
      
   The the input to this decider specifies a sequence   
   that cannot possibly reach its final halt state.   
      
   > The user just wants to know, does this thing halt or not?   
   >   
      
   The user may equally want a purely imaginary   
   Turing machine to bake a birthday cake.   
      
   > How does it answer the user's question?   
   >   
      
   As far as theoretical limitations go I have addressed   
   them. Practical workarounds can be addressed after I   
   am published and my work is accepted.   
      
   > The user's question is not incorrect; it may be incorrect when   
   > posed to H, in which case the user needs some other H, like H1.   
   >   
   > How do they decide between H and H1?   
   >   
   >   
      
   --   
   Copyright 2025 Olcott "Talent hits a target no one else can hit; Genius   
   hits a target no one else can see." Arthur Schopenhauer   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)