srand versus srandom - srand with random() safe?

[Arijit Das]

Can srand() be safely used for seeding subsequent random() calls?

And vice versa? Can srandom() be used for seeding subsequent rand()
calls?

Are these independent random number generators?

I tried few small examples and things seem to work by inter-mixing/
changing these (srand with random and vice versa).

But, i am not sure if that is legal or they just working by chance or
some implementation side effect.

Wanted to understand what is the legal stand on this issue?

Arijit

 

[Joachim Schmitz]

Can srand() be safely used for seeding subsequent random() calls?

And vice versa? Can srandom() be used for seeding subsequent rand()
calls?

Are these independent random number generators?

I tried few small examples and things seem to work by inter-mixing/
changing these (srand with random and vice versa).

But, i am not sure if that is legal or they just working by chance or
some implementation side effect.

Wanted to understand what is the legal stand on this issue?

Arijit

rand/srand is ANSI C, random/srandom is POSIX. Whether it is safe or not to
intermix them, it is not advisable, to say the least.

Bye, Jojo

 

[Ben Bacarisse]

Can srand() be safely used for seeding subsequent random() calls?

And vice versa? Can srandom() be used for seeding subsequent rand()
calls?

Because seeding an RNG should be a once-off action, and the seed is
essentially arbitrary, it probably doesn't matter much. But one of the
most common errors that people make is to seed an RNG too often in an
attempt to "mix things up" more.

Are these independent random number generators?

This question makes me think you might be seeding more often than you
should. Even if rand and random are totally linked, seeding one with
the other (properly seeded) is most likely harmless. The problems would
come if the generators are linked in some way and you seed one with the
other on several occasions (or, worse, very often).

Ideally, you should always seed a generator with a properly random
source, but if you don't have access to enough "entropy", doing this:

unsigned int seed = get_really_random_bits();
srandom(seed);
srand(seed);

is pretty much the same as doing this:

unsigned int seed = get_really_random_bits();
srandom(seed);
srand((unsigned int)random());

provided that this happens once.

Quite apart from seeding one with the other, mixing RNGS is inherently
dangerous. You could move your code to a system where rand() and
random() calls produce "related" numbers no matter how you seed them.
There will be uses where this won't matter but there will be others were
this will matter a lot. It all makes me wonder why you need to do this,
and if it can't be avoided somehow.

<snip>

 

[Nobody]

Can srand() be safely used for seeding subsequent random() calls?

And vice versa? Can srandom() be used for seeding subsequent rand()
calls?

Are these independent random number generators?

random/srandom aren't specified by ISO C, but by POSIX. POSIX.1-2008 says:

The implementation shall behave as if no function defined in this volume
of POSIX.1-2008 calls rand() or srand().

So random and srandom mustn't affect the values returned by rand(),
although the converse isn't necessarily true.

If you're using POSIX and you want independent PRNGs, use e.g. nrand48()
instead.

 

[Morris Keesan]

random/srandom aren't specified by ISO C, but by POSIX. POSIX.1-2008
says:


So random and srandom mustn't affect the values returned by rand(),
although the converse isn't necessarily true.

And if you use the "wrong" seed function, your program will appear to
work. But the descriptions of rand() and random() say that if
they're called without a previous call to the corresponding initializer
function, they behave as if they've been initialized with a seed of 1.
So it's likely that you'll get the same sequence of pseudo-random numbers
each time your program is called.

 

[James H. Markowitz]

Because seeding an RNG should be a once-off action, and the seed is
essentially arbitrary, it probably doesn't matter much. But one of the
most common errors that people make is to seed an RNG too often in an
attempt to "mix things up" more.

How do you determine "too often", and why would that be an error?
I understand it would perhaps be a waste of computational resources, but
not an error. Leaving the "too often" admonition aside, and assuming the
use of genuine random seeds, is seeding a PRNG regularly (unpredictably,
if possible) not a good idea?

 

[Keith Thompson]

How do you determine "too often", and why would that be an error?
I understand it would perhaps be a waste of computational resources, but
not an error. Leaving the "too often" admonition aside, and assuming the
use of genuine random seeds, is seeding a PRNG regularly (unpredictably,
if possible) not a good idea?

Unless you have a specific need to repeat a known sequence, a PRNG
should be seeded exactly once during the execution of the program,
before any calls to the generator.

It's rand()'s job to generate pseudo-random numbers. Re-seeding it just
interferes with it.

 

[Keith Thompson]

It is possible to cripple a really good pseudo-random number generator
with a poor seed. If you use a really good one that won't repeat
within 2**1024 lifetimes of the universe, and seed it with a 16-bit
number, all I have to do is try the 65,536 combinations of the seed.
Note that some versions of rand() only accept a 16-bit number (and
perhaps use only 15 bits of it). RAND_MAX is only required to be
at least 32767, so you might be seeding random() with a 15-bit
number.

[...]

RAND_MAX is the maximum value that rand() will return; it's at
least 32767 and at most INT_MAX.

The argument to srand() is of type unsigned int, so the maximum
seed value is UINT_MAX, not RAND_MAX.

An implementation might have RAND_MAX==32767, but accept 32-bit
seeds and generate 2**32 distinct sequences of 15-bit pseudo-random
numbers. (It could also accept 32-bit seeds and ignore all but 16
bits, or even fewer.)

 

[Ben Bacarisse]

How do you determine "too often", and why would that be an error?
I understand it would perhaps be a waste of computational resources, but
not an error. Leaving the "too often" admonition aside, and assuming the
use of genuine random seeds, is seeding a PRNG regularly (unpredictably,
if possible) not a good idea?

The error I was referring to was re-seeding with a seed that is not
genuinely random. Doing this will normally result in a decrease in the
quality of the random numbers. Doing so with a genuinely random seed is
safe but wasteful -- wasteful of a resource that is often scarce and
shared. I agree that it's a stretch to call that an error, but it was
not the case I was thinking of.

 

[Ben Bacarisse]

On 10/17/2011 06:19 PM, Gordon Burditt wrote:
...

The OP asked "Can srand() be safely used for seeding subsequent random()
calls?" He wasn't asking about rand().

Ha! So he did. I think a lot of the replies missed this fact. Mine
certainly did. The simple answer, then, is no.

 

[rudolf]

On 10/17/2011 06:19 PM, Gordon Burditt wrote:
...

The OP asked "Can srand() be safely used for seeding subsequent random()
calls?" He wasn't asking about rand().

He was asking about both.

From the OP:
Can srand() be safely used for seeding subsequent random() calls?

And vice versa? Can srandom() be used for seeding subsequent rand()
calls?

 

[Keith Thompson]

He was asking about both.

From the OP:
Can srand() be safely used for seeding subsequent random() calls?

And vice versa? Can srandom() be used for seeding subsequent rand()
calls?

But not about using the result of rand() as a seed for either.

The question was whether rand() and random() share data, so that srand()
and srandom() can affect both. (And the answer is no.)

 

[Nick Keighley]

more than once

where are you getting these from? And how many pounds of them do you
have?

The error I was referring to was re-seeding with a seed that is not
genuinely random.

but "genuinely random" might be rarer than thought. The current time
for instance probably isn't GR.