XPost: comp.theory, comp.lang.c++   
   From: polcott333@gmail.com   
      
   On 11/18/2025 10:52 PM, Kaz Kylheku wrote:   
   > On 2025-11-19, olcott  wrote:   
   >> On 11/18/2025 10:31 PM, Kaz Kylheku wrote:   
   >>> On 2025-11-19, olcott  wrote:   
   >>>> On 11/18/2025 8:53 PM, Kaz Kylheku wrote:   
   >>>>> On 2025-11-19, olcott  wrote:   
   >>>>>> On 11/18/2025 7:01 PM, Kaz Kylheku wrote:   
   >>>>>>> On 2025-11-18, olcott  wrote:   
   >>>>>>>> On 11/18/2025 3:21 PM, Kaz Kylheku wrote:   
   >>>>>>>>> On 2025-11-18, olcott  wrote:   
   >>>>>>>>>> If you ask a decider to determine if my   
   >>>>>>>>>> sister's name is "Sally" and I don't tell   
   >>>>>>>>>> it who I am then the information contained   
   >>>>>>>>>> in the input is insufficient. This does not   
   >>>>>>>>>> in any way limit computation itself.   
   >>>>>>>>>   
   >>>>>>>>> The problem is that UTM(D) can work out the fact that   
   >>>>>>>>> D halts. Why is it that UTM knows that D's sister's   
   >>>>>>>>> name is Sally, but H does not?   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> UTM(D) is answering a different question.   
   >>>>>>>> (a) It is not providing any answer at all.   
   >>>>>>>   
   >>>>>>> Well, of course, by "UTM" we mean a /decider/ that purely simulates:   
   >>>>>>>   
   >>>>>>>      bool UTM(ptr P) {   
   >>>>>>>        sim S = sim_create(P);   
   >>>>>>>        sim_step_exhaustively(S);   
   >>>>>>>        return true;   
   >>>>>>>      }   
   >>>>>>>   
   >>>>>>> All deciders applied to D are tasked with answering exactly the same   
   >>>>>>> question.   
   >>>>>>>   
   >>>>>>> Pretending that a different question was asked is nonproductive;   
   >>>>>>> the answer will be interpreted to the original question.   
   >>>>>>>   
   >>>>>>> All the information needed to answer is positively contained in D.   
   >>>>>>>   
   >>>>>>> It is just too complex relative to H.   
   >>>>>>>   
   >>>>>>   
   >>>>>> What The F does UTM decide when DD calls UTM(DD)?   
   >>>>>   
   >>>>> That doesn't happen; DD calls HHH(DD).   
   >>>>>   
   >>>>> A diagonal functon set against UTM, call it DDUTM,   
   >>>>> cannot be decided by UTM(DDUTM).   
   >>>>>   
   >>>>> That call simply does not return.   
   >>>>>   
   >>>>   
   >>>> Yes, and the other one does return proving the   
   >>>> whole point that I have been making for three   
   >>>> years that everyone (besides Ben) was too damned   
   >>>> dishonest to acknowledge has been true all along.   
   >>>   
   >>> What "other one"? Is that referring to HHH(DD)?   
   >>>   
   >>> HHH(DD) returns; UTM(DDUTM) does not return.   
   >>>   
   >>> That's four functions; HHH isn't UTM; DD isn't DDUTM.   
   >>>   
   >>> HHH and DDUTM are unrelated; UTM and DD are unrelated.   
   >>>   
   >>   
   >> void DDD()   
   >> {   
   >>     HHH(DDD);   
   >>     return;   
   >> }   
   >>   
   >> A simulating termination analyzer that must   
   >> abort the interpretation of the above ASCII   
   >> string to prevent its own non-termination   
   >> has different behavior than a simulating   
   >> termination analyzer that need not abort   
   >> its interpretation of the above exact same   
   >> ASCII string.   
   >   
   > 1. Up to that abort point, UTM(DDD) and HHH(DDD) conduct an   
   > absolutely identical simulation. The only difference is   
   > that the simulation continues under UTM, and is abandoned   
   > under HHH.   
   >   
      
   No that is counter-factual please try again.   
      
   > 2. This is not a difference attributable to DDD.  DDD is the same in   
   > both cases. Not continuing the simulation fo DDD doesn't redefine what   
   > DDD is. It is not possible to redefine what DDD is; it is the   
   > agreed-upon procedure above.   
   >   
      
      
   --   
   Copyright 2025 Olcott   
      
   My 28 year goal has been to make   
   "true on the basis of meaning" computable.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)