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