Random and Pseudo-random number generation

Question

I heard that computation results can be very sensitive to choice of random number generator.

1. I wonder whether it is relevant to program own Mersenne-Twister or other pseudo-random routines to get a good number generator. Also, I don't see why I should not trust native or library generators as random.uniform() in numpy, rand() in C++. I understand that I can build generators on my own for distributions other than uniform (inverse repartition function methor, polar method). But is it evil to use one built-in generator for uniform sampling?

2. What is wrong with the default 'time' seed? Should one re-seed and how frequently in a code sample (and why)?

3. Maybe you have some good links on these topics!

--edit More precisely, I need random numbers for multistart optimization routines, and for uniform space sample to initialize some other optimization routine parameters. I also need random numbers for Monte Carlo methods (sensibility analysis). I hope the precisions help figure out the scope of question.

Kind regards

Answer 1

The answers to those questions depend completely on what you need the pseudorandom numbers for.

In some applications, such as cryptography, one needs to use very, very random numbers, and it is essential that nobody can predict which number your generator produced, and also that nobody can deduce afterward which numbers were produced, except to the extent you explicitly tell them. In such a setting, seeding with the current time is obviously worthless, because an attacker can just set his computer's time to when he knows you (say) generated your key pair and then run the same random generator to figure out what it must have been.

In most other cases you care less about your random numbers being secret, and the CPU load that goes into ensuring that they are would be ill spent.

In yet other applications, such as some Monte Carlo simulations, you actually want the sequence of random numbers to be predictable and reproducible such that you can cross-check the computation later, or if you want to see how slightly different starting conditions would develop under the same "random" external influences.

It's all, completely, in what your needs are. And until you understand this connection better, it would certainly be a waste of effort to program your own generator just because you've heard that (in some situations!) it is the "right thing" to do.

Answer 2

Let's take your points one by one.

1. Is it relevant to program your own PRNG? Not really. Someone already did it for you. There is no more reason to program a PRNG than it is to write your own hash function; that is, only if you're not satisfies with the performance of the library function. In the case of the PRNG, there can be two reasons. The first one is that the PRNG isn't random enough. This is the case for some really old standard C functions, whose pseudorandomness might actually be noticeable by your Monte Carlo simulation. But if you use anything reasonably new, you're fine in this regard. The second one is that the PRNG is too slow. That's not usually a problem since modern PRNG are pretty fast, and the processing that you do far outweighs the time required to generate the numbers. But if you do ever find yourself in this situation, ask here, and either someone will give you a faster PRNG, or explain why you don't really need it.

2. Should you use time to generate the seed? When doing Monte Carlo simulations, you want your experiments to be reproducible. Also, you sometimes want to test several variants of your code on the same random data. But it's not a sin to generate the random seeds (once and for all) using whatever method. In Unix you have a /dev/random you can use.

3. Any links? Lot of links, but I don't think they're relevant. It's better for you to concentrate on the actual thing that you're doing, rather on this aspect, which perhaps interests you, but is marginal (or should be) from your point of view. However, it's always good to be inquisitive, so if you feel like, explore. Just don't think that it has any bearing on your actual simulations.