home bbs files messages ]

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

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

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

   Message 241,957 of 243,242   
   olcott to Kaz Kylheku   
   Re: Will keep posting this every day unt   
   14 Nov 25 12:19:33   
   
   XPost: comp.theory, comp.lang.c++   
   From: polcott333@gmail.com   
      
   On 11/14/2025 12:01 PM, Kaz Kylheku wrote:   
   > On 2025-11-14, olcott  wrote:   
   >> On 11/14/2025 12:35 AM, Kaz Kylheku wrote:   
   >>> On 2025-11-14, olcott  wrote:   
   >>>> On 11/13/2025 8:32 PM, Kaz Kylheku wrote:   
   >>>>> On 2025-11-14, olcott  wrote:   
   >>>>>> So you still don't understand that when H sees   
   >>>>>> that D calls the same function twice in sequence   
   >>>>>> with the same arguments and has no conditional   
   >>>>>> code inbetween its invocation and this function   
   >>>>>> call that this is isomorphic to infinite recursion?   
   >>>>>   
   >>>>> No. Obvious counterexample:   
   >>>>>   
   >>>>> void D(void)   
   >>>>> {   
   >>>>>      printf("calling this twice\n");   
   >>>>>      // no conditionals here   
   >>>>>      printf("calling this twice\n");   
   >>>>> }   
   >>>>>   
   >>>>> You're simply not able to run a simple specification through your head   
   >>>>> to identify the ways in which it might not reflect your intent.   
   >>>>>   
   >>>>   
   >>>> Why do you post such ridiculous nonsense?   
   >>>   
   >>> The above "D calls the same function (printf) twice in sequence with the   
   >>> same arguments ("calling this twice\n") and has no conditional code   
   >>> inbetween its invocation and this function call". It meets your   
   >>> criteria; therefore it must be "isomorphic to infinite recursion".   
   >>>   
   >>>> Are you a complete jackass or only partial?   
   >>>   
   >>> I'm only conveying to you that the above function meets the words you   
   >>> have written.   
   >>>   
   >>   
   >> OK then I apologize.   
   >   
   > My eyes must be deceiving me.   
   >   
   >>> If you didn't intend that, that is your problem. I'm just the messenger.   
   >>>   
   >>> Such a messenger wouldn't be necessary if you could think for yourself.   
   >>>   
   >>   
   >> https://github.com/plolcott/x86utm/blob/master/Halt7.c   
   >> I forgot a detail on line 996   
   >>   
   >> Calls the same function from the same machine address   
   >> with no conditional branches in between its invocation   
   >> and this function call.   
   >   
   > Now suppose that we wrongly place execution events from all   
   > threads into a single buffer.   
   >   
   > It can now happen like this:   
   >   
   > void D(void)   
   > {   
   >     (void) thread_create(D);   
   >     thread_exit(0);   
   > }   
   >   
   > main()   
   > {   
   >     (void) thread_create(D);   
   > }   
   >   
   > The repeated call in question is D calling thread_create.   
   >   
   > The call happens multiple times, from the same address, without   
   > intervening conditional instructions (assuming we do not   
   > trace system functions thread_create and thread_exit).   
   >   
   > In our single trace buffer, it /appears/ to meet the conditions for   
   > identifying runaway recursion.   
   >   
   > Yet, do you not see that the threads are all terminating?   
   >   
   > Every single new thread dispatched to D creates a new thread, which is   
   > an asynchronous action, and then promptly terminates.   
   >   
   > The /process/ will keep spawning new threads and fail to terminate.  But   
   > that's not the question. When we ask whether D terminates, we are not   
   > asking whether D is surrounded by a reality which terminates.   
   >   
   >>> Your idea that when a decider abandons a simulation and returns zero,   
   >>> the simuation is "totally killed" does not hold water. Mathematical   
   >>> entities are never "killed".   
   >>>   
   >>   
   >> The above non-halting behavior axiom is correct.   
   >> It conclusively proves the D simulated by H cannot   
   >> possibly ever reach its own simulated "return"   
   >> statement.   
   >   
   > It doesn't. What is correct is the trick in the halting proof, that no   
   > decider could be correct when deciding its diagonal case.   
   >   
   > Those who are skeptical can dissect into particular complex cases to see   
   > how they play out: i.e. to articulate in more detail why such and such a   
   > diagonal pair case is incorrect. It is largely moot.   
   >   
   > In your case, your logic is incorrect even for non-diagonal cases,   
   > such as:   
   >   
   >    void DDD(void) {   
   >       HHH(DDD);   
   >       return;   
   >    }   
   >   
   > For this non-diagonal case, your HHH could return 1 and be correct.   
   > DDD does not behave opposite to the 1 return value; it confirms it.   
   >   
      
      
   On 5/8/2025 8:30 PM, Keith Thompson wrote:   
    > 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.   
    >   
      
   news://text.giganews.com/87seled0zy.fsf@nosuchdomain.example.com   
      
   --   
   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