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 242,784 of 243,242   
   Michael S to All   
   Re: Article of Melissa O'Nail   
   05 Jan 26 14:21:44   
   
   From: already5chosen@yahoo.com   
      
   I experimented a bit more (in fact, more like a lot more) with   
   test batteries of L’Ecuyer. It led me to conclusion that occasional   
   failure in the either middle or big battery means nothing.    
   Sometimes even cripto-quality PRNG does not pass one or another test.   
   Then you try to reproduce it and see that with any other seed that you   
   try a failure does not happen.   
   All in all, it makes me more suspect of PRNGs that consistently pass   
   both batteries with various seed. I start to see it as a sign of   
   PRNG being rigged to pass tests.   
      
   Said above does not apply to scomp_LinearComp() failures of mt19937.   
   Those failures are very consistent. I just don't consider them   
   significant for my own use of PRNGs or for any other uses of PRNG that   
   I personally ever encountered.   
      
   Overall an experience strengthened my position that general wisdom,   
   previously shared by O'Neil herself, got it right: in absence of the   
   special considerations people should select mt19937 and especially   
   mt19937-64 as their default PRNGs of choice.   
   Looking closer, apart from its properties of randomness and apart from   
   huge period (which does not matter for me) I started to appreciate for   
   mt19937 for the following properties that I was not aware before:   
   - it does not use multiplier. So good fit for embedded systems that   
     have no (or very slow) multiplier HW.   
   - algorithm is very SIMD-friendly, so optimized implementations can be   
     very very fast on modern x86 and ARM64 hardware.   
   The latter property also means that very fast FPGA implementation is   
   easily possible as long as designer is willing to through at it   
   moderate amount of logic resources.   
      
   Said above does not mean that PCG generators of O'Neil have no place.   
   Intuitively, they appear not bad. But the theory is unproven, optimized   
   implementation is likely slower that optimized mt19937, claimed   
   "security" advantages are nonsense as admitted later by O'Neil herself.   
   And, as said above, I no longer trust her empirical methodology, based   
   on work of L’Ecuyer.    
   So, PCG generators are valuable addition to the toolbox, but not good   
   enough to change my default.   
      
   --- 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