XPost: comp.theory, sci.logic, sci.math   
   From: hal@discovery.nasa   
      
   On Sun, 16 Nov 2025 09:29:48 -0600, olcott wrote:   
      
   > On 11/16/2025 6:42 AM, HAL 9000 wrote:   
   >> On Sat, 15 Nov 2025 19:14:00 -0600, olcott wrote:   
   >>   
   >>> On 11/15/2025 6:56 PM, HAL 9000 wrote:   
   >>>> On Fri, 14 Nov 2025 13:52:14 -0600, olcott wrote:   
   >>>>   
   >>>>> On 5/8/2025 8:30 PM, Keith Thompson wrote:   
   >>>>>> olcott  writes:   
   >>>>>>> On 5/8/2025 6:49 PM, Keith Thompson wrote:   
   >>>>>>>> olcott  writes:   
   >>>>>>>> [...]   
   >>>>>>>>> void DDD()   
   >>>>>>>>> {   
   >>>>>>>>>       HHH(DDD);   
   >>>>>>>>>       return;   
   >>>>>>>>> }   
   >>>>>>>>>   
   >>>>>>>>> If you are a competent C programmer then you know that DDD   
   >>>>>>>>> correctly simulated by HHH cannot possibly each its own "return"   
   >>>>>>>>> instruction.   
   >>>>>>>> "cannot possibly each"?   
   >>>>>   
   >>>>> This is what On 5/8/2025 8:30 PM, Keith Thompson wrote:   
   >>>>> is responding to below:   
   >>>>>   
   >>>>>>>> I am a competent C programmer (and I don't believe you can make   
   >>>>>>>> the same claim).  I don't know what HHH is.  The name "HHH" tells   
   >>>>>>>> me nothing about what it's supposed to do.  Without knowing what   
   >>>>>>>> HHH is,   
   >>>>>>>> I can't say much about your code (or is it pseudo-code?).   
   >>>>>>>>   
   >>>>>>>>   
   >>>>>>> For the purpose of this discussion HHH is exactly what I said it   
   >>>>>>> is.   
   >>>>>>> It correctly simulates DDD.   
   >>>>>>   
   >>>>>> Does HHH correctly simulate DDD *and do nothing else*?   
   >>>>>>   
   >>>>>> Does HHH correctly simulate *every* function whose address is   
   >>>>>> passed to it?  Must the passed function be one that takes no   
   >>>>>> arguments and does not return a value?   
   >>>>>>   
   >>>>>> Can HHH just *call* the function whose address is passed to it?   
   >>>>>> If it's a correct simulation, there should be no difference between   
   >>>>>> calling the function and "correctly simulating" it.   
   >>>>>>   
   >>>>>> My knowledge of C tells me nothing about *how* HHH might simulate   
   >>>>>> DDD.   
   >>>>>>   
   >>>>>>> We need not know anything else about HHH to know that DDD   
   >>>>>>> correctly simulated by HHH cannot possibly REACH its own "return"   
   >>>>>>> instruction.   
   >>>>>>   
   >>>>>>   
   >>>>> *Here is his response *   
   >>>>>   
   >>>>>> Assuming that HHH(DDD) "correctly simulates" DDD, and assuming it   
   >>>>>> does nothing else, your code would be equivalent to this:   
   >>>>>>   
   >>>>>>        void DDD(void) {   
   >>>>>>            DDD(); return;   
   >>>>>>        }   
   >>>>>>   
   >>>>>> Then the return statement (which is unnecessary anyway) will never   
   >>>>>> be reached.  In practice, the program will likely crash due to a   
   >>>>>> stack overflow, unless the compiler implements tail-call   
   >>>>>> optimization, in which case the program might just run forever --   
   >>>>>> which also means the unnecessary return statement will never be   
   >>>>>> reached.   
   >>>>>>   
   >>>>>>   
   >>>> That is only the case if HHH is of an erroneous design: whatever HHH   
   >>>> does with DDD should NOT leak out of HHH so your SHD is designed   
   >>>> incorrectly. If HHH(DDD) reports non-halting then DDD will halt thus   
   >>>> HHH is erroneous.   
   >>>>   
   >>>> /HAL   
   >>>>   
   >>>>   
   >>>>   
   >>> It great to have someone new here, welcome.   
   >>>   
   >>> https://github.com/plolcott/x86utm/blob/master/Halt7.c Simulating   
   >>> termination analyzer HHH and input DD have been a fully operational   
   >>> software system for more than three years.   
   >>>   
   >>> typedef int (*ptr)();   
   >>> int HHH(ptr P);   
   >>>   
   >>> int DD()   
   >>> {   
   >>>     int Halt_Status = HHH(DD);   
   >>>     if (Halt_Status)   
   >>>       HERE: goto HERE;   
   >>>     return Halt_Status;   
   >>> }   
   >>>   
   >>> int main()   
   >>> {   
   >>>     HHH(DD);   
   >>> }   
   >>>   
   >>> When N statements of DD are simulated by HHH according to the   
   >>> semantics of the C programming language the simulated DD cannot reach   
   >>> its own simulated "return" statement final halt state for any value of   
   >>> N.   
   >>>   
   >>> HHH report on the actual behavior that its actual input actually   
   >>> specifies as measured by DD simulated by HHH.   
   >>>   
   >>> HHH cannot possibly report on the behavior of its caller because HHH   
   >>> has no way of knowing what function is calling it.   
   >>>   
   >>> This means that when the halting problem requires HHH to report on the   
   >>> behavior of its caller: DD() that its is requiring something outside   
   >>> the scope of computation,   
   >>   
   >> No, if HHH(DD) reports non-halting to DD then DD will halt thus HHH is   
   >> erroneous.   
   >>   
   >> /HAL   
   >>   
   >>   
   >>   
   > That is the key objection to my work.   
   >   
   > The information that HHH is required to report on simply is not   
   > contained in its input.   
   >   
   > HHH cannot report on the behavior of its caller because it has no way of   
   > even knowing which function called it. The same thing applies to the   
   > Peter Linz Turing machine version.   
   >   
   > HHH(DD) does correctly report on the behavior that its input specifies.   
   > No decider can ever report on more than that.   
   >   
   > int sum(int x, int y){ return x + y;}   
   > sum(3,4) cannot report on the sum of 5+6 even if required to do so. That   
   > requirement is incorrect.   
   >   
   > I have worked on this for 28 years because:   
   > If the halting problem is correct then the notion of "true on the basis   
   > of meaning" is broken.   
      
   DD halts.   
      
   /HAL   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)