XPost: comp.theory, comp.lang.c++   
   From: 643-408-1753@kylheku.com   
      
   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.   
      
   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.   
      
   --   
   TXR Programming Language: http://nongnu.org/txr   
   Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal   
   Mastodon: @Kazinator@mstdn.ca   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)