summaryrefslogtreecommitdiff
path: root/src/prng/rand_r.c
AgeCommit message (Collapse)AuthorFilesLines
2013-06-12improve the quality of output from rand_rRich Felker1-1/+10
due to the interface requirement of having the full state contained in a single object of type unsigned int, it is difficult to provide a reasonable-quality implementation; most good PRNGs are immediately ruled out because they need larger state. the old rand_r gave very poor output (very short period) in its lower bits; normally, it's desirable to throw away the low bits (as in rand()) when using a LCG, but this is not possible since the state is only 32 bits and we need 31 bits of output. glibc's rand_r uses the same LCG as musl's, but runs it for 3 iterations and only takes 10-11 bits from each iteration to construct the output value. this partially fixes the period issue, but introduces bias: not all outputs have the same frequency, and many do not appear at all. with such a low period, the bias is likely to be observable. I tried many approaches to "fix" rand_r, and the simplest I found which made it pass the "dieharder" tests was applying this transformation to the output. the "temper" function is taken from mersenne twister, where it seems to have been chosen for some rigorous properties; here, the only formal property I'm using is that it's one-to-one and thus avoids introducing bias. should further deficiencies in rand_r be reported, the obvious "best" solution is applying a 32-bit cryptographic block cipher in CTR mode. I identified several possible ciphers that could be used directly or adapted, but as they would be a lot slower and larger, I do not see a justification for using them unless the current rand_r proves deficient for some real-world use.
2013-06-08prng: make rand_r have 2^32 period instead of 2^31Szabolcs Nagy1-1/+1
this is a minor fix to increase the period of the obsolete rand_r a bit. an include header in __rand48_step.c is fixed as well.
2011-02-12initial check-in, version 0.5.0v0.5.0Rich Felker1-0/+6