home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.ai.philosophy      Perhaps we should ask SkyNet about this      59,235 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 57,685 of 59,235   
   olcott to Fred. Zwarts   
   Re: Title: A Structural Analysis of the    
   28 Jul 25 07:46:08   
   
   XPost: comp.theory, sci.logic   
   From: polcott333@gmail.com   
      
   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.   
      
      
   --   
   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)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca