4

Have you ever written simulations or randomized algorithms where you've run into trouble because of the quality of the (pseudo)-random numbers you used?

What was happening?

How did you detect / realize your prng was the problem?

Was switching PRNGs enough to fix the problem, or did you have to switch to a source of true randomness?

I'm trying to figure out what types of applications require one to worry about the quality of their source of randomness and how one realizes when this becomes a problem.

Dr. belisarius
  • 60,527
  • 15
  • 115
  • 190
Jesse Cohen
  • 4,010
  • 22
  • 25

2 Answers2

3
  1. The dated random number generator RANDU was infamous in the seventies for producing "bad" random numbers. My PhD supervisor mentioned that it affected his PhD and he had to rerun simulations. A search on Google for RANDU linear congrunetial generator brings up other examples.
  2. When I run simulations on multiple machines, I've sometimes been tempted to generate "random seeds", rather than just use a proper parallel random number generator. For example, generate the seed using the current time in seconds. This has caused me enough problems that I avoid this at all costs.

This is mainly due to my particular interests, but other than parallel computing, the thought of creating my own random number generator would never cross my mind. Calling a well tested random number function is trivial in most languages.

csgillespie
  • 59,189
  • 14
  • 150
  • 185
1

It is a good practice to run your prng against DieHard. Very good and fast PRNG exist nowadays (see the work of Marsaglia), see Numerical Recipes edition 3 for a good introduction.

Alexandre C.
  • 55,948
  • 11
  • 128
  • 197