XPost: comp.theory, comp.lang.c, comp.lang.c++   
   From: polcott333@gmail.com   
      
   On 9/19/2025 8:22 PM, vallor wrote:   
   > On Fri, 19 Sep 2025 10:02:58 -0500, olcott  wrote in   
   > <10ajrb4$ik2f$1@dont-email.me>:   
   >   
   >> On 9/19/2025 5:31 AM, vallor wrote:   
   >>> On Fri, 19 Sep 2025 10:49:15 +0200, "Fred. Zwarts"    
   >>> wrote in <10aj5ea$cf6i$5@dont-email.me>:   
   >>>   
   >>>> Op 19.sep.2025 om 03:51 schreef olcott:   
   >>>>> On 9/18/2025 8:38 PM, Kaz Kylheku wrote:   
   >>>>> The pattern that you outlined is exactly the same as the recursion   
   >>>>> depth of mutual recursion.   
   >>>>>   
   >>>>> It is easy to cheat and come to some other fake conclusion. No other   
   >>>>> correct conclusion exists.   
   >>>>>   
   >>>> The failure of a simulator to reach the final halt state is not a   
   >>>> proof for non-termination behaviour.   
   >>>>   
   >>>> In particular when other simulators have proven that the exact same   
   >>>> input specifies a program for which the final halt state can be   
   >>>> reached.   
   >>>> That is true for the HHH that aborts after two cycles of recursion.   
   >>>> What we see is that 1) If HHH does not abort, it does not provide any   
   >>>> answer,   
   >>>> so it fails. 2) If HHH does abort, it aborts prematurely, because the   
   >>>> input has changed. A correct simulation would reach the final halt   
   >>>> state one cycle later. It is incorrect for HHH to report on another   
   >>>> hypothetical input with a different finite string that include the HHH   
   >>>> that does not abort.   
   >>>> It mus abort on the input that includes the HHH that aborts.   
   >>>>   
   >>>> You confuse your self by not clearly separating the input and the code   
   >>>> of the decider. But a TM cannot report about another TM, so the full   
   >>>> program, DDD including all functions called by it directly or   
   >>>> indirectly, in particular including the HHH called by DDD, must be   
   >>>> part of the input.   
   >>>   
   >>> By George, I think this is the crux of Olcott's confusion.  I know you   
   >>> all understand this, but I don't think Peter does:   
   >>>   
   >>> Ignoring for a second that the "machine string" he's passing to HHH()   
   >>> is a pointer, consider the string to which the pointer points:  it is a   
   >>> function that includes a call to HHH().  So a good chunk of HHH() is   
   >>> part of the input string, including the parts that cause the actual   
   >>> paradox:  DD() halts, because it has "decided" (incorrectly) that it   
   >>> doesn't halt.  But it does, because it includes the code from HHH.   
   >>>   
   >>> Peter, If you run DD() by itself, it halts -- and let's not hear   
   >>> anymore of this talk about HHH() and DD() being none of each other's   
   >>> business, because the code for DD() includes the code for HHH(),   
   >>> standalone or otherwise.   
   >>>   
   >>>   
   >> When we make HHH an integral part of the operating system that checks   
   >> every function called from main() then yet again main-->DD() is rejected   
   >> as non-halting.   
   >> main-->DD() has always specified the equivalent of infinite recursion.   
   >   
   > But DD() includes the specification of HHH(DD) (by reference) -- ignoring   
   > the results of HHH(DD) isn't allowed.   
   >   
   > Consider the call to HHH() if it were inlined.  You have a considerable   
   > chunk of your halt decider guts as part of the DD input string.  You   
   > can't ignore that and hand-wave it away -- and that is the crux of the   
   > matter:  you continue to ignore a very large chunk of the input string.   
   >   
   >> When HHH sees it right away it says it right away. When HHH does not see   
   >> it until the second recursive call then it makes it looks like   
   >> main-->DD() halted on its own without intervention.   
   >   
   > It did halt on its own, because DD() calls HHH(), which points to a   
   > considerable amount of code that you seem to be hand-waving away.   
   >   
   >> Everyone here knows that intervention was required or main-->DD() would   
   >> have never halted yet ignore this so that they can remain in   
   >> disagreement mode.   
   >   
   > Actually, everyone can see (even me) that that-which-is-referred-to-by   
   > HHH is part of the input string DD.  You can't ignore that.   
   >   
   > What I did figure out (by putting myself in your shoes) is that you   
   > apparently don't consider that-which-is-referred-to by HHH as part   
   > of (that-which-is-referred-to-by) DD.   
   >   
   > Crudely, the input string DD contains the contents of HHH.  You   
   > can't ignore that.   
   >   
      
   int P()   
   {   
      int Halt_Status = H(P);   
      if (Halt_Status)   
        HERE: goto HERE;   
      return Halt_Status;   
   }   
      
   int main()   
   {   
      H(P);   
      return 0;   
   }   
      
   While DD is simulated by HHH according to the   
   semantics of the C programing language the   
   simulated DD cannot possibly reach its own   
   simulated "return" statement final halt state.   
      
   --   
   Copyright 2025 Olcott

   
      
   My 28 year goal has been to make 
   
   "true on the basis of meaning expressed in language"
   
   reliably computable.

   
      
   This required establishing a new foundation
   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)