On Fri, Mar 11, 2016 at 4:33 PM, Manlio Perillo wrote:
Is it really ok to use, as part of the standard library, a random number
generator with no documentation, no studies in the literature, and no info
about algorithm quality in statistical tests like TestU01?
I think the Mitchell/Reeds PRNG in math/rand stems from Plan9, and has been
lifted from the Plan9 C library. You are correct later PRNGs exist.
Roughly, the problem with an old PRNG can be that its period is too small
on new hardware. The Wichmann/Hill PRNG in Erlang could go through its full
period in a little bit less than 24 hours on modern machines, so it was
changed to an XorShift variant. The API was also extended so it could be
augmented with new PRNGs and thus remain mostly compatible forward-looking,
with the default PRNG choice changed as new ones will be adopted. The
Mersenne Twister is another well-known PRNG with a large period. If you
also support splitting a seed into multiple seeds, then the period matter
even more, but I don't think that is the case for the Go PRNG.
The point of math/rand is to be able to produce a deterministic random
source so you can something which "looks random", but can be reproduced.
The large period usually ends up mattering if you use the PRNG as a basis
for a monte-carlo style simulation, where a small period can produce
problems (after a while, the same numbers are traversed again).
The point of crypto/rand is that it is a CSPRNG, which is needed for
cryptographic security. Its primary property is that you can do no better
than 50% on predicting the next bit coming out of it, even with a large
history of existing bits. But these are usually an order of magnitude
slower than PRNGs, and thus unsuitable for simulations.
Personally, I always look up the PRNG primitive in order to understand if
it fits my purpose. I think it is a fine PRNG for running tests in random
order and so on. I'd probably hesitate using it for long-running
simulations. If not, rolling your own implmentation of the Source and Rand
interfaces on top of another kind of random source and PRNG should be
fairly easy to do. And you should obtain almost seamless integration.
If you think the PRNG is too weak, you better start computing its period on
modern hardware and you can also send it through the usual PRNG tests which
are state-of-the-art. This could demonstrate, backed up with numbers, that
the default PRNG is too weak in period or randomness.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
For more options, visit https://groups.google.com/d/optout.