One simple way of generating a random number from A to B (exclusive) is to use a function like this:

int rand(int begin, int end)
{
assert(begin < end);
int range = end - begin;
return begin + (std::rand() % range);
}

For small ranges, the above can be biased. For instance, a similar implementation (in C#) I tested in a recent thread had a significant bias towards odd numbers.

An alternative is the following:


int rand(int begin, int end)
{
assert(begin < end);
float r = std::rand() / static_cast<float>(RAND_MAX);
int range = end - begin;
return begin + static_cast<int>(r * range);
}


int main()
{
srand(time(0));
cout << 1+(rand()%10) <<endl;

This code seemed to do the trick from getting numbers from 1-10.


That's good enough for practice or any "non-serious" use, but as rip-off pointed out, you will NOT have the same probability for all numbers (though depending on your range).

A quick and dirty test of how unequally distributed your numbers are would be something like:


int counts[10] = {0};
int samples = 1000000;
while (samples-- > 0)
++counts[ rand() % 10 ];

std::copy(counts, counts+10, ostream_iterator<int>(cout, " "));
/* Yes, you could just do for (int i=0; i<10; ++i) cout << counts << " "; */
cout << endl;


If you run this multiple times and any of the values is consistently and significantly larger than others, you already know which number you should probably always guess first.

One simple way of generating a random number from A to B (exclusive) is to use a function like this:

int rand(int begin, int end)
{
assert(begin < end);
int range = end - begin;
return begin + (std::rand() % range);
}

For small ranges, the above can be biased. For instance, a similar implementation (in C#) I tested in a recent thread had a significant bias towards odd numbers.

An alternative is the following:


int rand(int begin, int end)
{
assert(begin < end);
float r = std::rand() / static_cast<float>(RAND_MAX);
int range = end - begin;
return begin + static_cast<int>(r * range);
}


That doesn't remove the bias at all though, it just attempts to hide it. Specifically rather than the lower outcomes having a higher probability, the same number of values have a similarly slightly higher probability but the ones that do are spread across the range.
E.g. The best way to examine such a thing is to pretend you have a much smaller random number of bits. Say you had a 4-bit random number generator and you wanted to generate a number from 0-5, (perhaps for a die roll where you add 1 afterwards to get 1-6).

Using the basic mod method you would get

• 0 if rand() was 0, 6, or 12
  
• 1 if rand() was 1, 7, or 13
  
• 2 if rand() was 2, 8, or 14
  
• 3 if rand() was 3, 9, or 15
  
• 4 if rand() was 4 or 10
  
• 5 if rand() was 5 or 11
  

With the code involving the conversion to and from floating point you get:

• 0 if rand() was 0, 1, or 2
  
• 1 if rand() was 3, or 4
  
• 2 if rand() was 5, 6, or 7
  
• 3 if rand() was 8 or 9
  
• 4 if rand() was 10, 11, or 12
  
• 5 if rand() was 13 or 14,
  
• 6 if rand() was 15 (bug!!!)
  

Note the bug I even found upon actually using the floating point method above, to map inputs to outputs. That was with a range of 5. Using a range of 6 all except the last outcome come from 3 possible inputs and the last only comes from one possible input, also very biased.

The problem is that you still have the same number of inputs going to the same number of outputs. So you at best only manage to sweep the bias under the rug.

Here is the rejection method, which I've previously posted on another site. It completely solves the bias problem:
// Generates random number between min and max, inclusive.
int random(int min, int max)
{
int range, result, cutoff, divisor;
if (min >= max)
return min; // only one outcome possible, or invalid parameters
range = max-min+1;
divisor = RAND_MAX / range;
cutoff = divisor * range;
// Rejection method, to be statistically unbiased.
do {
result = std::rand();
} while (result >= cutoff);
return result / divisor + min;
}Note that this is a slight improvement over what I've previously posted on a different site, where this version also helps avoid the slight lack of randomness in the lower bits of rand.

Back to the 4-bit generator example. With the plain old mod method notice how there are three ways to get 0-3 but only two ways of getting 4-5. This is statistically biased towards the lower numbers! So the rejection method would throw away any random number of 12 or above and try again. That way there are exactly two ways of arriving at each outcome. (The calculation for cutoff calculates 12 in this case due to the integer division result of 15 / 6 being 2, and 2 * 6 = 12)

With the rejection method above you get:

• 0 if rand() was 0 or 1
  
• 1 if rand() was 2 or 3
  
• 2 if rand() was 4 or 5
  
• 3 if rand() was 6 or 7
  
• 4 if rand() was 8 or 9
  
• 5 if rand() was 10 or 11
  

All outcomes are now equally likely.

About the loop:
Here it is ignoring 4 values out of 16 so it will loop around again 1/4th of the time, but in a real situation it loops so few times you do not have to worry about it. E.g. when getting a random number for a die roll using random number generator that gives a 15-bit output, it loops only 4 out of 32767 times. That's small enough that you don't need to worry about it. The chance of that looping even 4 times is 0.000000000018%

Last but not least, make sure that you call srand only once in your program, preferably inside main.

Oh and one final note, on Windows, the ultimate random number generator is CryptGenRandom. :-)

With the code involving the conversion to and from floating point you get:

• 0 if rand() was 0, 1, or 2
  
• 1 if rand() was 3, or 4
  
• 2 if rand() was 5, 6, or 7
  
• 3 if rand() was 8 or 9
  
• 4 if rand() was 10, 11, or 12
  
• 5 if rand() was 13 or 14,
  
• 6 if rand() was 15 (bug!!!)
  

[/quote]
Hmm? For the case rand() is 15, then r = 1.0f. The result is begin + (r * range), where range is 5. So the result would be 5 in this case, not 6. Am I wrong?

In fact, this is the output I get:

• 0 if rand() is 0, 1 or 2
  
• 1 if rand() is 3, 4 or 5
  
• 2 if rand() is 6, 7 or 8
  
• 3 if rand() is 9, 10 or 11
  
• 4 if rand() is 12, 13 or 14
  
• 5 if rand() is 15
  

Now, we still have a problem because 5 is significantly less likely to appear. So your correction is warranted.

With the rejection method above you get...

[/quote]
Ok, that is indeed better.

I was thinking of the wrong problem, I believe a corrected version of the function I provided could be used to extend the range of values above RAND_MAX (without calling rand() multiple times). E.g. We want a potentially very large float or double, but we're happy to accept a sample of RAND_MAX values in that range (as opposed to mandating that any value in the range could appear).

Oh and one final note, on Windows, the ultimate random number generator is CryptGenRandom. :-)
[/quote]
For applications requiring cryptographic random numbers, sure.