Thread: Modulus and Random number generation.

But the math is incorrect. According to this web site, rand() can return anything from 0 to RAND_MAX, which is why you want to clamp the result down to anything from min to max. The size of the range matters when you use the % operator, not the max itself.

number1 = number1 % (max - min) + min;

You could also do:

Code:

do 
   number1 = rand();
while (number1 < min || number1 > max);

This requires no math, but you have to wait for rand to return a number that works. That's the only drawback.

Originally Posted by whiteflags

This requires no math, but you have to wait for rand to return a number that works. That's the only drawback.

And sometimes you have to wait forever because rand really doesn't know how to create uniform distributions. Plus, it's also deprecated.
I suggest you use the new random number generation facilities in C++ if your compiler supports C++11: std::uniform_int_distribution - cppreference.com

Originally Posted by Elysia

And sometimes you have to wait forever because rand really doesn't know how to create uniform distributions.

That's not quite accurate. Non-uniformity doesn't mean it's possible for some numbers to never occur, it simply implies that they may not occur quite as often as others.

What whiteflags posted is the wrong way to implement the rejection method. If you have a moment, it would be handy if you could review my recent draft article on generating evenly distributed random numbers, which also happens to explain how to do it properly:
Random Numbers

This site does point out some historical rand implementations really were crap, but I would imagine that anything less than 10 years old would typically be adequate for many purposes:

There are no guarantees as to the quality of the random sequence produced. In the past, some implementations of rand() have had serious shortcomings in the randomness, distribution and period of the sequence produced (in one well-known example, the low-order bit simply alternated between 1 and 0 between calls).

rand() is not recommended for serious random-number generation needs, like cryptography. It is recommended to use C++11's random number generation facilities to replace rand().(since C++11)

Originally Posted by iMalc

That's not quite accurate. Non-uniformity doesn't mean it's possible for some numbers to never occur, it simply implies that they may not occur quite as often as others.

I did not literally mean forever. I meant, as you said, that for some numbers, the probability is really low. I have run into situations where I've pretty much run into an endless loop trying to rand some specific numbers.
The distribution is also really, really poor when I tested on Visual C++, so if that bothers you, then that's another reason not to use it.

Originally Posted by Elysia

I did not literally mean forever. I meant, as you said, that for some numbers, the probability is really low. I have run into situations where I've pretty much run into an endless loop trying to rand some specific numbers.

Right, but as noted, the above is not how to properly implement the rejection method. One fact within the article I wrote is that in the worst case there is always less than 50% chance of the rand() value being rejected, and it is typically far lower than that.

The distribution is also really, really poor when I tested on Visual C++, so if that bothers you, then that's another reason not to use it.

That's out of context to the point of being untrue.
One can write a program to perform statistical analysis on it's rand() output, and uncover some issues if you know what to look for, but generally these things are unnoticeable for common applications. Visual C++ implementations have always had a good period period of 2^32 (source) and consequently a perfectly even distribution in the long run. They can be faulted yes, but "really, really poor" is a gross exaggeration.

People who try to point out bias in the implementation of Visual Studio's rand implementation generally have actually introduced the bias themselves by using purely a modulus operation to reduce the output range.