Updated: now there is an attachment. Four 64 bit variables a, b, c, d. To seed, a,b,c get something seed dependent. d gets 0, ignoring the seed (this is important to get some guaranteed properties). The update function is: 1. do something that mixes up a, b, c in a reversible way. 2. add an odd constant to d. 3. add d into one of a,b,c If you want a 64 bit variate with 64 bits of apparent entropy, use a. This guarantees a minimum cycle length, and that streams from different seeds will not run into...
Four 64 bit variables a, b, c, d. To seed, a,b,c get something seed dependent. d gets 0, ignoring the seed (this is important to get some guaranteed properties). The update function is: 1. do something that mixes up a, b, c in a reversible way. 2. add an odd constant to d. 3. add d into one of a,b,c If you want a 64 bit variate with 64 bits of apparent entropy, use a. This guarantees a minimum cycle length, and that streams from different seeds will not run into each other for at least pow(2,64)...
BigCrush is part of testu01. https://simul.iro.umontreal.ca/testu01/tu01.html is probably a good place to start.
Hi, these numbers look good. Biologists and social scientists used to get excited about anything outside the 95% confidence interval. Problem: 5% chance of a false positive. Now most are moving to a 99.9% interval. In our case (testing fast prngs) getting more data is cheap. Why risk false alarms? Do lots of data and only fail at extremely low P-value. (And yes, as you managed to find somewhere in the docs, I try to design the tests so only very low P-values are bad. P-values near 1 are not a problem.)...
Don't use this for serious security.
And here's the notes. I'll add that i suspect the prng is not all that good. Whether it's bad enough to invalidate the actual application is hard to know. Often even quite bad prngs can be useful, but not always. Hopefully in the rewrite of the application, there will be some thought to being able to replace the prng with minimal pain, so at least two different prngs can be tested to see how consistent results are. Best of luck.
I've done some hacks to your c++ code. I think the approach is slightly different to Lorenzo's and possibly a more useful way to convert double to 32 bit unsigned int. Unfortunately it is untested as i don't yet have a fortran compiler. Notes follow in the next comment. Ignore if you're happy with what you've already got.
Thanks for doing this testing. I'll look at this at home and try to do a version that works on cygwin as well as POSIX. Since cygwin is not very different this should be achieveable, whereas native MS-Windows probably needs a completely different build process. Presumably there are similar problems in a few other source directories too.