C++ Random Number Question

[JC0133]

Probably a dumb question but I haven't found anything on google.

How can I create a 16-BIT random number?

 

[Ken g6]

Generally, rand() generates a random number with at least 15 random bits. So you'd want to either cut off bits if you have too many, or concatenate bits (with left-shift, <<, and or, |) from multiple random numbers if you have too few.

Is this a random number where all 16 bits are random, or a random number with 16 significant bits, i.e. in the range 0x8000-0xFFFF?

 

[mv2devnull]

I would presume that contents of <random> can answer both of those.
See http://en.cppreference.com/w/cpp/numeric/random

 

[JC0133]

Generally, rand() generates a random number with at least 15 random bits. So you'd want to either cut off bits if you have too many, or concatenate bits (with left-shift, <<, and or, |) from multiple random numbers if you have too few.

Is this a random number where all 16 bits are random, or a random number with 16 significant bits, i.e. in the range 0x8000-0xFFFF?

All 16 bits are random. Like I can do .

Can I do this ?
int16_t bitNum = rand()%100; //bitNum in the range of 0 to 99.

?

 

[Ken g6]

All 16 bits are random. Like I can do .

Can I do this ?
int16_t bitNum = rand()%100; //bitNum in the range of 0 to 99.

?

That's not ideal. Imagine if your random number generator returned a single decimal digit, and you need a random number between 0 and 7. Then using %8, there's a 1 in 10 chance of getting each number between 2 and 7, but a 2 in 10 chance of getting 0, and of getting 1.

It does work if the original range is divisible by the desired result range. That's why bit shifts work in the case you started the thread with.

 

[mv2devnull]

Here we "roll" 20 random numbers and then show them as binary. The XXX are important lines.

// uniform_int_distribution example
#include <iostream>
#include <chrono>
#include <random>
#include <bitset>

int main()
{
  // construct a trivial random generator engine from a time-based seed:
  unsigned seed = std::chrono::system_clock::now().time_since_epoch().count();
  std::mt19937 generator (seed); // XXX
  std::uniform_int_distribution<int> distribution(0, 0xFFFF); // XXX

  std::cout << std::bitset<16>( 0 ) << " is min\n";
  for (size_t c=0; c<20; ++c) {
    int number = distribution(generator); // XXX
    std::cout << std::bitset<16>( number ) << '\n';
  }
  std::cout << std::bitset<16>( 0xFFFF ) << " is max\n";

  return 0;
}

Possible output:

0000000000000000 is min
1011100100111110
1111000010100001
1100111110011101
0110010011101000
1111000110100110
0101000000001111
1001111100000110
1100000100011101
1010100000110101
0101001000001011
0110101000010100
0110011000010110
1010101101110011
1100111101000010
0001000010101010
1100111010100000
0001101000100000
1111001011100111
1111101111011100
0110011111011000
1111111111111111 is max

 

[Merad]

Here we "roll" 20 random numbers and then show them as binary. The XXX are important lines.

Note that this is not the correct way to seed MT19937. While it "works", it shouldn't be used for any real world application. You're only seeding 4 bytes of entropy into an algorithm that has a state of 2.5 KB, making it relatively easy to brute force your seed value, and therefore expose your entire sequence of random numbers to an attacker. If you're interested in the details read the first link, if you just want to know how to seed correctly read the second link.

http://www.pcg-random.org/posts/cpp-seeding-surprises.html
https://kristerw.blogspot.com/2017/05/seeding-stdmt19937-random-number-engine.html

 

[sweenish]

Note that this is not the correct way to seed MT19937. While it "works", it shouldn't be used for any real world application. You're only seeding 4 bytes of entropy into an algorithm that has a state of 624 bytes, making it relatively easy to brute force your seed value, and therefore expose your entire sequence of random numbers to an attacker. If you're interested in the details read the first link, if you just want to know how to seed correctly read the second link.

http://www.pcg-random.org/posts/cpp-seeding-surprises.html
https://kristerw.blogspot.com/2017/05/seeding-stdmt19937-random-number-engine.html

I'd say this is a "depends" type thing. 2^32 states may well be enough for your purposes. These are good educational reads, and a lot of devs may feel that using something like std::random_device is sufficient for their needs. A better statement is that this isn't the best way to seed mt19937. "Correct" can have a few different meanings in this case.

For something like dice rolls, where you'd be passing your PRNG through a std::uniform_int_distribution<>, I think the system time or std::random_device is "good enough."

 

[Merad]

I'd say this is a "depends" type thing. 2^32 states may well be enough for your purposes. These are good educational reads, and a lot of devs may feel that using something like std::random_device is sufficient for their needs. A better statement is that this isn't the best way to seed mt19937. "Correct" can have a few different meanings in this case.

Disagree. If you read the first article, it elaborates on how a partial initialization causes bias in the number generation, which has a lot of potential to cause problems or quirks in your application. I dare say that many (probably most) programmers don't really have the math & statistics knowledge to fully understand how that choice affects number generation, so they're far better off to just add the two extra lines needed for correct initialization.

 

[sweenish]

Like you said, potential to cause problems. If I'm just rolling some dice, it will likely go unnoticed. Maybe my current uses just aren't to a scale necessary to care too much.

I do agree with the author that better initialization through proper support in <random> would make the problem go away.

 

[mv2devnull]

Stephan T. Lavavej did describe C++11's <random> in https://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful
While he does not touch the issues of mt19937 seeding that we discuss now, he presents a neat case of "Do you want to use something that looks ok but is certainly not perfect (modulo) or alternative that ought to do the right magic (uniform_int_distribution)?"

I dare say that many (probably most) programmers don't really have the math & statistics knowledge to fully understand how that choice affects number generation

Quite likely. However, those links have worrisome tidbits too.

1. Walfridsson writes: "at least old versions of libstdc++ on MinGW always return the same sequence of values"
In other words, the std::random_device can be totally not random if you use a nasty implementation. Even the "some dice" should notice if you do.

2. M.E. O'Neill writes: "Blame std::seed_seq After All ... "
Even when we initialize seed_seq with enough good entropy, it can offer bad biased seeds to mt19937. Scary.
The further posts by M.E. O'Neill offer an alternative seeder. http://www.pcg-random.org/posts/simple-portable-cpp-seed-entropy.html