XPost: comp.theory, sci.logic   
   From: polcott333@gmail.com   
      
   On 7/29/2025 8:37 PM, Richard Damon wrote:   
   > On 7/29/25 9:18 PM, olcott wrote:   
   >> On 7/29/2025 5:38 PM, Richard Damon wrote:   
   >>> On 7/29/25 5:15 PM, olcott wrote:   
   >>>> On 7/29/2025 2:39 AM, Fred. Zwarts wrote:   
   >>>>> Op 28.jul.2025 om 14:46 schreef olcott:   
   >>>>>> On 7/28/2025 3:43 AM, Fred. Zwarts wrote:   
   >>>>>>> Op 26.jul.2025 om 20:46 schreef olcott:   
   >>>>>>>> On 7/26/2025 1:11 PM, joes wrote:   
   >>>>>>>>> Am Sat, 26 Jul 2025 08:48:48 -0500 schrieb olcott:   
   >>>>>>>>>> On 7/26/2025 3:05 AM, joes wrote:   
   >>>>>>>>>>> Am Fri, 25 Jul 2025 15:02:16 -0500 schrieb olcott:   
   >>>>>>>>>>>> On 7/25/2025 2:10 PM, joes wrote:   
   >>>>>>>>>>>>> Am Fri, 25 Jul 2025 11:32:03 -0500 schrieb olcott:   
   >>>>>>>>>   
   >>>>>>>>>>>>> Oh, really now? I thought it referred to its simulator HHH   
   >>>>>>>>>>>>> by name.   
   >>>>>>>>>>>> The actual code has always been based on an x86 emulator   
   >>>>>>>>>>>> that emulates   
   >>>>>>>>>>>> finite strings of x86 machine code bytes.   
   >>>>>>>>>>> But does DDD call whatever is behind the name "HHH" or does   
   >>>>>>>>>>> it call the   
   >>>>>>>>>>> fixed code that aborts just before the second recursive call?   
   >>>>>>>>>>> Because   
   >>>>>>>>>>> DDD calling a modified HHH' is a different program.   
   >>>>>>>>>> When HHH emulates DDD then DDD calls HHH(DDD) based on   
   >>>>>>>>>> whatever code is   
   >>>>>>>>>> at machine address 000015d2.   
   >>>>>>>>> Ok, so modifying HHH to simulate further also changes the input   
   >>>>>>>>> DDD,   
   >>>>>>>>> because it calls the same address. Gotcha.   
   >>>>>>>>>   
   >>>>>>>>>>>> For three years everyone here acts like it is impossible for   
   >>>>>>>>>>>> them to   
   >>>>>>>>>>>> understand that the correct emulation of an input that calls   
   >>>>>>>>>>>> its own   
   >>>>>>>>>>>> emulator HHH(DDD) can possibly be different than the   
   >>>>>>>>>>>> emulation of the   
   >>>>>>>>>>>> same input that does not call its own emulator HHH1(DDD).   
   >>>>>>>>>>> It is not impossible to understand. It is wrong.   
   >>>>>>>>>> Since the execution trace conclusively proves that it is   
   >>>>>>>>>> correct your   
   >>>>>>>>>> mere intuition to the contrary is proven to be incorrect.   
   >>>>>>>>> The trace only shows it is different. It remains to be shown   
   >>>>>>>>> that the   
   >>>>>>>>> abort was correct.   
   >>>>>>>>>   
   >>>>>>>>>>> If we prefix all programs we pass to HHH with DDD, they   
   >>>>>>>>>>> should not be   
   >>>>>>>>>>> aborted as if the were the same.   
   >>>>>>>>>>> If HHH were a correct simulator, it would produce the same   
   >>>>>>>>>>> behaviour as   
   >>>>>>>>>>> an UTM. (HHH1 is the same as HHH, right?)   
   >>>>>>>>> Right?   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> All of the chatbots figure out that I am correct   
   >>>>>>>> on their own. I only give them this input:   
   >>>>>>>>   
   >>>>>>>> typedef void (*ptr)();   
   >>>>>>>> int HHH(ptr P);   
   >>>>>>>>   
   >>>>>>>> void DDD()   
   >>>>>>>> {   
   >>>>>>>>    HHH(DDD);   
   >>>>>>>>    return;   
   >>>>>>>> }   
   >>>>>>>>   
   >>>>>>>>   
   >>>>>>>> int main()   
   >>>>>>>> {   
   >>>>>>>>    HHH(DDD);   
   >>>>>>>>    DDD();   
   >>>>>>>> }   
   >>>>>>>>   
   >>>>>>>> Simulating Termination Analyzer HHH correctly simulates its   
   >>>>>>>> input until:   
   >>>>>>>> (a) It detects a non-terminating behavior pattern then it aborts   
   >>>>>>>> its simulation and returns 0,   
   >>>>>>>> (b) Its simulated input reaches its simulated "return" statement   
   >>>>>>>> then it returns 1.   
   >>>>>>>   
   >>>>>>> These cache-boxes are fed with invalid and contradictory   
   >>>>>>> information:   
   >>>>>>> (a) No non-termination pattern can be detected when it aborts and   
   >>>>>>> return, because the simulated HHH is also programmed to abort and   
   >>>>>>> return.   
   >>>>>>   
   >>>>>> DDD correctly simulated by HHH cannot possibly reach its own   
   >>>>>> simulated "return" instruction final halt state in one to   
   >>>>>> infinity steps of correct simulation. This is a verified fact.   
   >>>>>>   
   >>>>>>   
   >>>>> As usual incorrect claims without evidence.   
   >>>>> Your dreams are no verified facts. HHH aborts before the simulation   
   >>>>> would reach the final halt state in a finite number of steps, as   
   >>>>> proven by world-class simulators using exactly the same input. The   
   >>>>> infinity is only in your dreams.   
   >>>>>   
   >>>>   
   >>>> HHH(DDD) must simulate itself simulating DDD because DDD calls HHH(DDD)   
   >>>   
   >>> And must CORRECTLY (amd completely) simulate that.   
   >>>   
   >>   
   >> No you fucking liar a person can count to ten   
   >> without counting to infinity.   
   >>   
   >   
   > Sure, and you can simulate the first 4 instructions of DDD. But that   
   > doesn't say you know or show what DDD will do.   
   >   
      
   It is the repeating sequence that cannot possibly   
   reach the "return" instruction final halt state of   
   DDD that is recognized in a finite number of steps.   
      
   I know that you are smart enough to see this so that   
   only leaves liar.   
      
   --   
   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)