On 03/03/2013 09:58 AM, Ivan Kazmenko wrote:
I have to ask: what would be a good unpredictableSeed by definition? With the
current implementation, three downsides come to my mind:
1. Process ID, thread ID and system tick are insecure sources of randomness and
can provide just a few bits of randomness in certain situations. I don't know
how to address this in a portable way.
2. Once we know the first seed, it is easy to predict all subsequent seeds. A
solution would be to use a secure RNG instead, not just the one which gives away
its state.
I have to say that in my case, I'm not interested in security, but merely in
having a statistically good enough seeding for parallel simulations. That is, I
want multiple parallel streams of random numbers that are independent to the
highest possible degree.
But, you have a point, and if unpredictableSeed is good enough for my
application, it may not be good enough for others. (Though I'm not sure e.g.
Mersenne Twister is adequate for crypto in the first place.)
That said, is it as un-random and predictable as you say? I'd have anticipated
that the combination of process ID, thread ID and system tick would generate
quite a good seed for Mersenne Twister, but I don't have the theoretical
argument to back it up. :-(
3. It would be a particularly bad idea to initialize MinstdRand0 instances with
consecutive unpredictableSeeds and then consider them independent. This is just
a consequence of a particular choice of RNG on the previous step.
Is MinstdRand0 really something you should consider using at all, if you care
about quality statistics?
So, which of these do you consider the real problems, and what more do you need
from unpredictableSeed?
I need _statistically_ thread-safe pseudo-random number generation for the
purposes of scientific simulation -- so, I don't care about the theoretical
predictability, but about the quality of approximation of randomness. I'm using
rndGen (so, Mersenne Twister on my x86-64 system) with anything from 2-20
different threads.
My broader interest here is more theoretical, though, because I'd like to see
std.random equipped with the best possible tools for the job -- and there are a
number of existing niggles with it that spark my paranoia about other aspects :-)
