Issues with seeding a pseudo-random number generator more than once?

Question

I've seen quite a few recommendations for not seeding pseudo-random number generators more than once per execution, but never accompanied by a thorough explanation. Of course, it is easy to see why the following (C/C++) example is not a good idea:

int get_rand() {
  srand(time(NULL));
  return rand();
}

since calling get_rand several times per second produces repeated results.

But wouldn't the following example still be an acceptable solution?

MyRand.h

#ifndef MY_RAND_H
#define MY_RAND_H

class MyRand
{
  public:
    MyRand();
    int get_rand() const;
  private:
    static unsigned int seed_base;
};

#endif

MyRand.cpp

#include <ctime>
#include <cstdlib>
#include "MyRand.h"

unsigned int MyRand::seed_base = static_cast<unsigned int>(time(NULL));

MyRand::MyRand()
{
  srand(seed_base++);
}

int MyRand::get_rand() const
{
  return rand();
}

main.cpp

#include <iostream>
#include "MyRand.h"

int main(int argc, char *argv[]) 
{
  for (int i = 0; i < 100; i++) 
  {
    MyRand r;
    std::cout << r.get_rand() << " ";
  }
}

i.e. even though MyRand:s constructor is called several times in rapid succession, each call to srand has a different parameter. Obviously, this is not thread-safe, but then again neither is rand.

Complex

I might add that the whole purpose of this exercise is to relieve the "burden" of calling srand from the client of MyRand, where MyRand might be modelling a die. But on the other hand, if we also build fortune wheels, coin tosses etc. in the same way, we will get a lot of seeds. – Complex

Answer 1

Each time you call a pseudo-random number generator function, the generator takes some internal state and produces a pseudo-random number and a new internal state. The algorithm for transforming the internal state is carefully chosen so the output appears random.

When you seed the random number generator, you're basically setting this internal state. If you reset the internal state to some predictable value, you'll lose the appearance of randomness.

For example, a popular, simple RNG is a linear congruential generator. Numbers are generated like this:

X[n+1] = (a X[n] + c) mod m

In this case, X[n+1] is both the result and the new internal state. If you seed the generator every time as you suggest above, you'll get a sequence that looks like this:

{(ab + c) mod m, (a(b+1) + c) mod m, (a(b+2) + c) mod m, ...}

where b is your seed_base. This doesn't look random at all.

Hungary

My main.cpp example is a little exaggerated for the purpose of demonstrating the lack of the first example's flaw. Instantiating a new object for each call to get_rand will lead to the situation you describe above, but that's just wasteful programming. Assuming that the number of MyRand instantiations are few compared to get_rand calls, things look a little better. – Complex

Answer 2

If your seed is predictable, which it is here since you're just incrementing it, the output from rand() will also be predictable.

It really depends on why you want to generate random numbers, and how "random" is an acceptable random for you. In your example, it may avoid duplicates in rapid succession, and that may be good enough for you. After all, what matters is that it runs.

On almost every platform there is a better way to generate random numbers than rand().

Seldon

Answer 3

Well it's extra processing that doesn't need to be done.

In that scenario I'd just call the constructor once with a time-based seed before the start of the loop. That will guarantee random results without the extra overhead of changing seeds for every iteration.

I wouldn't think your method is any more random than that.

Cauca

Answer 4

You can think of random number generation (this is not strictly true implementation-wise any more, but serves as an illustration) as a table of values. If you remember doing any of this stuff in statistics for doing simple random samples, a seed basically tells you what row and column to start at in your big table of random numbers. Reseeding over and over again is simply unnecessary since we can already assume that the numbers are normally distributed already.

There is simply no added benefit to seeding more than once since this should be good enough (depending on the application). If you do need "more" random numbers, there are many methods of random number generation. One case that I can think of is to generate random numbers in a thread-safe manner.

While your solution is acceptable, your numbers will be no more random than seeding it once, globally. srand generally shouldn't belong in a constructor. If you'd like to support random numbers, seed once when the program starts, and forget about it.

Washedout