73

I use the following code to test the C++ <random> library.

Why do I get the exact same sequence for every run of the compiled executable? Is rd() deterministic upon compilation? How do I get different output for each run?

GCC 4.8.1 on Windows 7 64bit. Using MinGW distribution from http://nuwen.net/mingw.html.

EDIT: I tested the same piece code with Visual Studio. There is no problem. The outputs are non deterministic. This could be a bug in mingw gcc 4.8.1 that I used.

#include <iostream> #include <random> using namespace std; int main(){ random_device rd; mt19937 mt(rd()); uniform_int_distribution<int> dist(0,99); for (int i = 0; i< 16; ++i){ cout<<dist(mt)<<" "; } cout <<endl; }
Improve this question
10
  • 5
    Platform and compiler please. This should definitely not happen, even with entropy() == 0. If it does, that’s a bug. Commented Sep 18, 2013 at 19:51
  • 9
    @MM. No, that’s not how random_device works. Commented Sep 18, 2013 at 19:55
  • 5
    Could you make the compiler print the contents of the macro _GLIBCXX_USE_RANDOM_TR1 please? If it’s 0, then it’s using mt19937 with a fixed seed as a fallback. Commented Sep 18, 2013 at 19:58
  • 3
    Bug is still present in mingw-w64 with gcc 4.9.2 Commented Mar 8, 2015 at 13:01
  • 4
    Has anybody tried reporting a bug to GCC so it can be fixed? Or is that too much to ask? Commented Mar 23, 2017 at 16:28

5 Answers 5

Reset to default
35

From http://en.cppreference.com/w/cpp/numeric/random/random_device:

Note that std::random_device may be implemented in terms of a pseudo-random number engine if a non-deterministic source (e.g. a hardware device) is not available to the implementation.

I would expect a decent implementation to at least seed the RNG though.

Edit: I suspect they deliberately chose to deliver the same sequence each time, to make obvious the fact that the stream wasn't as random as promised.

Improve this answer
Sign up to request clarification or add additional context in comments.

3 Comments

I agree. The fallback implementation of stdlibc++ uses a constant seed, which doesn’t strike me as all that smart (and it’s not explained).
The real failure is to have this pseudo-random fallback in the first place.
@ypnos: the standard has to do something to cover the case of a C++ implementation on a deterministic platform. But doing that on a real platform is a huge quality-of-implementation issue. See also How to succinctly, portably, and thoroughly seed the mt19937 PRNG?.
26

I got a confirmed answer from STL from MSFT:

Unlike VC, GCC hasn't implemented random_device nondeterministically on Windows. Boost has, so you can use Boost.Random.

Improve this answer

1 Comment

I have yet to find an appropriate doc indicating which boost lib -l's and what order boosts -l's are needed in gcc to avoid link errors, and any system -l also required. Just adding -lboost-random-mgw48-mt-d-1_57 resulted in the linker complaing there was no boost::random::random_device() and no boost::random::~random_device()
6

This is a GCC bug, fixed in GCC 9.2.

If you have this problem, update your compiler. (You can get a fresh GCC from MSYS2, for example.)

Improve this answer

3 Comments

@northerner Run pacman -Syuu. There's a change that it will close the terminal (and all msys2 programs) to proceed; an older version will ask you to do it manually. If any of that happened, you have to restart MSYS2 and run the same command again to complete the update.
The update fails stackoverflow.com/questions/63201980/… Also I already have GCC 9.1 and random_device still doesn't work.
@northerner Well, as I said it was fixed in GCC 9.2, and your version is older than that. Try reinstalling MSYS2.
4

You may need to pass a parameter to the constructor:

https://gcc.gnu.org/onlinedocs/gcc-4.9.1/libstdc++/api/a00899.html

Improve this answer

Comments

2

  1. GCC does not implement rd.entropy() correctly - it always returns 0 (at least on Mac OS X).

  2. Unfortunately, there seems to be no way to mix additional entropy into random_device, which matters because it usually/often (look at Linux /dev/random and /dev/urandom, and at the Intel RDRAND implementation) implements a pseudo-random number generator under the hood. I'd like to be able to improve its output by injecting something I consider random to mix with whatever its entropy source produces. Again, since this device (or kernel module) internally implements a cryptographic algorithm for processing the entropy bits it obtains to generate its output, I'd like to be able to "randomize" that process more by injecting my own data to mix with whatever entropy that device picks. For example, consider Java SecureRandom(). It does not allow you to set the seed (which indeed would convert it to PRNG), but it would happily mix what you provide with whatever it is using to "randomize" its output even more.

  3. I personally prefer RDRAND. A small assembly library with a compact C interface. Here are the references:

    David Johnson from Intel explains RDRAND on Stackoverflow

    Stackoverflow pointers to RDRAND library source for Windows, Linux, and Mac OS X

    Intel blog on RDRAND library, and a download link

Improve this answer

10 Comments

It does not make sense to seed random_device. If it requires a seed, then it is a pseudo-random generator, not a true random number generator, which is what random_device is supposed to be.
"Seed" was an unfortunate term. You do not "seed" a "true" random_device. But since random devices such as provided by Linux (and even RDRAND that's firmware-implemented) involve software algorithms between their entropy sources and their output available to users, mixing in randomness/entropy from other sources can't hurt the outcome, and sometimes can improve it. I think you should retract your downvote, if you are honest.
I think the answer is confusingly written, if you rewrite it then i might retract my downvote. There is a difference between pseudorandom generation and randomness extraction. Theoretically, it works like this. Given a weakly random source, e.g. maybe 1000 bits with only 100 bits of entropy in them, first you want to use an extractor to get ~ 50 bits with ~ 50 bits of entropy in them. In practice this uses a cryptographic hash function. Then the result can be used as a seed to a generator, which stretches the 50 bits to many many more bits for use in your application. (Numbers made up.)
Nice. I was not aware that you could write to /dev/random. Now I know better: add a file as entropy source and why writing to /dev/random.... XORing the additional entropy into the result is a good and efficient way - with the disadvantage of being explicit.
I think the Java model is the best because it allows the rest of the program that utilizes SecureRandom to be unaware of all those details and improvements, and simply use the standard interface of standard class as-is. Another advantage of the Java SecureRandom API is that it is resistant to corruption by "bad" randomness input by the user. The SecureRandom output can only improve (or stay at the same quality) with additional input.
|

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.