Search

5.9 — Random number generation

The ability to generate random numbers can be useful in certain kinds of programs, particularly in games, statistics modeling programs, and scientific simulations that need to model random events. Take games for example -- without random events, monsters would always attack you the same way, you’d always find the same treasure, the dungeon layout would never change, etc… and that would not make for a very good game.

So how do we generate random numbers? In real life, we often generate random results by doing things like flipping a coin, rolling a dice, or shuffling a deck of cards. These events involve so many physical variables (e.g. gravity, friction, air resistance, momentum, etc…) that they become almost impossible to predict or control, and produce results that are for all intents and purposes random.

However, computers aren’t designed to take advantage of physical variables -- your computer can’t toss a coin, throw a dice, or shuffle real cards. Computers live in a controlled electrical world where everything is binary (false or true) and there is no in-between. By their very nature, computers are designed to produce results that are as predictable as possible. When you tell the computer to calculate 2 + 2, you always want the answer to be 4. Not 3 or 5 on occasion.

Consequently, computers are generally incapable of generating random numbers. Instead, they must simulate randomness, which is most often done using pseudo-random number generators.

A pseudo-random number generator (PRNG) is a program that takes a starting number (called a seed), and performs mathematical operations on it to transform it into some other number that appears to be unrelated to the seed. It then takes that generated number and performs the same mathematical operation on it to transform it into a new number that appears unrelated to the number it was generated from. By continually applying the algorithm to the last generated number, it can generate a series of new numbers that will appear to be random if the algorithm is complex enough.

It’s actually fairly easy to write a PRNG. Here’s a short program that generates 100 pseudo-random numbers:

The result of this program is:

23070   27857   22756   10839   27946
11613   30448   21987   22070   1001
27388   5999    5442    28789   13576
28411   10830   29441   21780   23687
5466    2957    19232   24595   22118
14873   5932    31135   28018   32421
14648   10539   23166   22833   12612
28343   7562    18877   32592   19011
13974   20553   9052    15311   9634
27861   7528    17243   27310   8033
28020   24807   1466    26605   4992
5235    30406   18041   3980    24063
15826   15109   24984   15755   23262
17809   2468    13079   19946   26141
1968    16035   5878    7337    23484
24623   13826   26933   1480    6075
11022   19393   1492    25927   30234
17485   23520   18643   5926    21209
2028    16991   3634    30565   2552
20971   23358   12785   25092   30583

Each number appears to be pretty random with respect to the previous one. As it turns out, our algorithm actually isn’t very good, for reasons we will discuss later. But it does effectively illustrate the principle of PRNG number generation.

Generating random numbers in C++

C (and by extension C++) comes with a built-in pseudo-random number generator. It is implemented as two separate functions that live in the cstdlib header:

std::srand() sets the initial seed value to a value that is passed in by the caller. srand() should only be called once at the beginning of your program. This is usually done at the top of main().

std::rand() generates the next random number in the sequence. That number will be a pseudo-random integer between 0 and RAND_MAX, a constant in cstdlib that is typically set to 32767.

Here’s a sample program using these functions:

Here’s the output of this program:

17421	8558	19487	1344	26934	
7796	28102	15201	17869	6911	
4981	417	12650	28759	20778	
31890	23714	29127	15819	29971	
1069	25403	24427	9087	24392	
15886	11466	15140	19801	14365	
18458	18935	1746	16672	22281	
16517	21847	27194	7163	13869	
5923	27598	13463	15757	4520	
15765	8582	23866	22389	29933	
31607	180	17757	23924	31079	
30105	23254	32726	11295	18712	
29087	2787	4862	6569	6310	
21221	28152	12539	5672	23344	
28895	31278	21786	7674	15329	
10307	16840	1645	15699	8401	
22972	20731	24749	32505	29409	
17906	11989	17051	32232	592	
17312	32714	18411	17112	15510	
8830	32592	25957	1269	6793

PRNG sequences and seeding

If you run the std::rand() sample program above multiple times, you will note that it prints the same result every time! This means that while each number in the sequence is seemingly random with regards to the previous ones, the entire sequence is not random at all! And that means our program ends up totally predictable (the same inputs lead to the same outputs every time). There are cases where this can be useful or even desired (e.g. you want a scientific simulation to be repeatable, or you’re trying to debug why your random dungeon generator crashes).

But often, this is not what is desired. If you’re writing a game of hi-lo (where the user has 10 tries to guess a number, and the computer tells them whether their guess is too high or too low), you don’t want the program picking the same numbers each time. So let’s take a deeper look at why this is happening, and how we can fix it.

Remember that each number in a PRNG sequence is generated from the previous number, in a deterministic way. Thus, given any starting seed number, PRNGs will always generate the same sequence of numbers from that seed as a result! We are getting the same sequence because our starting seed number is always 5323.

In order to make our entire sequence randomized, we need some way to pick a seed that’s not a fixed number. The first answer that probably comes to mind is that we need a random number! That’s a good thought, but if we need a random number to generate random numbers, then we’re in a catch-22. It turns out, we really don’t need our seed to be a random number -- we just need to pick something that changes each time the program is run. Then we can use our PRNG to generate a unique sequence of pseudo-random numbers from that seed.

The commonly accepted method for doing this is to enlist the system clock. Each time the user runs the program, the time will be different. If we use this time value as our seed, then our program will generate a different sequence of numbers each time it is run!

C comes with a function called time() that returns the number of seconds since midnight on Jan 1, 1970. To use it, we merely need to include the ctime header, and then initialize srand() with a call to std::time(nullptr) (or std::time(0) if your compiler is pre-C++11).

Here’s the same program as above, using a call to time() as the seed:

Now our program will generate a different sequence of random numbers every time! Run it a couple of times and see for yourself.

Generating random numbers between two arbitrary values

Generally, we do not want random numbers between 0 and RAND_MAX -- we want numbers between two other values, which we’ll call min and max. For example, if we’re trying to simulate the user rolling a die, we want random numbers between 1 and 6 (pedantic grammar note: yes, die is the singular of dice).

Here’s a short function that converts the result of rand() into the range we want:

To simulate the roll of a die, we’d call getRandomNumber(1, 6). To pick a randomized digit, we’d call getRandomNumber(0, 9).

Optional reading: How does the previous function work?

The getRandomNumber() function may seem a little complicated, but it’s not too bad.

Let’s revisit our goal. The function rand() returns a number between 0 and RAND_MAX (inclusive). We want to somehow transform the result of rand() into a number between min and max (inclusive). This means that when we do our transformation, 0 should become min, and RAND_MAX should become max, with a uniform distribution of numbers in between.

We do that in five parts:

  1. We multiply our result from std::rand() by fraction. This converts the result of rand() to a floating point number between 0 (inclusive), and 1 (exclusive).

    If rand() returns a 0, then 0 * fraction is still 0. If rand() return RAND_MAX, then RAND_MAX * fraction is RAND_MAX / (RAND_MAX + 1), which is slightly less than 1. Any other number returned by rand() will be evenly distributed between these two points.

  2. Next, we need to know how many numbers we can possibly return. In other words, how many numbers are between min (inclusive) and max (inclusive)?

    This is simply (max - min + 1). For example, if max = 8 and min = 5, (max - min + 1) = (8 - 5 + 1) = 4. There are 4 numbers between 5 and 8 (that is, 5, 6, 7, and 8).

  3. We multiply the prior two results together. If we had a floating point number between 0 (inclusive) and 1 (exclusive), and then we multiply by (min - max + 1), we now have a floating point number between 0 (inclusive) and (max - min + 1) (exclusive).
  4. We cast the previous result to an integer. This removes any fractional component, leaving us with an integer result between 0 (inclusive) and (max - min) (inclusive).
  5. Finally, we add min, which shifts our result to an integer between min (inclusive) and max (inclusive).

Optional reading: Why don’t we use the modulus operator (%) in the previous function?

One of the most common questions readers have submitted is why we use division in the above function instead of modulus (%). The short answer is that the modulus method tends to be biased in favor of low numbers.

Let’s consider what would happen if the above function looked like this instead:

Seems similar, right? Let’s explore where this goes wrong. To simplify the example, let’s say that rand() always returns a random number between 0 and 9 (inclusive). For our sample case, we’ll pick min = 0, and max = 6. Thus, max - min + 1 is 7.

Now let’s calculate all possible outcomes:

0 + (0 % 7) = 0
0 + (1 % 7) = 1
0 + (2 % 7) = 2
0 + (3 % 7) = 3
0 + (4 % 7) = 4
0 + (5 % 7) = 5
0 + (6 % 7) = 6

0 + (7 % 7) = 0
0 + (8 % 7) = 1
0 + (9 % 7) = 2

Look at the distribution of results. The results 0 through 2 come up twice, whereas 3 through 6 come up only once. This method has a clear bias towards low results. By extension, most cases involving this algorithm will behave similarly.

Now lets take a look at the result of the getRandomNumber() function above, using the same parameters as above (rand() returns a number between 0 and 9 (inclusive), min = 0 and max = 6). In this case, fraction = 1 / (9 + 1) = 0.1. max - min + 1 is still 7.

Calculating all possible outcomes:

0 + static_cast(7 * (0 * 0.1))) = 0 + static_cast(0) = 0
0 + static_cast(7 * (1 * 0.1))) = 0 + static_cast(0.7) = 0
0 + static_cast(7 * (2 * 0.1))) = 0 + static_cast(1.4) = 1
0 + static_cast(7 * (3 * 0.1))) = 0 + static_cast(2.1) = 2
0 + static_cast(7 * (4 * 0.1))) = 0 + static_cast(2.8) = 2
0 + static_cast(7 * (5 * 0.1))) = 0 + static_cast(3.5) = 3
0 + static_cast(7 * (6 * 0.1))) = 0 + static_cast(4.2) = 4
0 + static_cast(7 * (7 * 0.1))) = 0 + static_cast(4.9) = 4
0 + static_cast(7 * (8 * 0.1))) = 0 + static_cast(5.6) = 5
0 + static_cast(7 * (9 * 0.1))) = 0 + static_cast(6.3) = 6

The bias here is still slightly towards lower numbers (0, 2, and 4 appear twice, whereas 1, 3, 5, and 6 appear once), but it’s much more uniformly distributed.

Even though getRandomNumber() is a little more complicated to understand than the modulus alternative, we advocate for the division method because it produces a less biased result.

What is a good PRNG?

As I mentioned above, the PRNG we wrote isn’t a very good one. This section will discuss the reasons why. It is optional reading because it’s not strictly related to C or C++, but if you like programming you will probably find it interesting anyway.

In order to be a good PRNG, the PRNG needs to exhibit a number of properties:

First, the PRNG should generate each number with approximately the same probability. This is called distribution uniformity. If some numbers are generated more often than others, the result of the program that uses the PRNG will be biased!

For example, let’s say you’re trying to write a random item generator for a game. You’ll pick a random number between 1 and 10, and if the result is a 10, the monster will drop a powerful item instead of a common one. You would expect a 1 in 10 chance of this happening. But if the underlying PRNG is not uniform, and generates a lot more 10s than it should, your players will end up getting more rare items than you’d intended, possibly trivializing the difficulty of your game.

Generating PRNGs that produce uniform results is difficult, and it’s one of the main reasons the PRNG we wrote at the top of this lesson isn’t a very good PRNG.

Second, the method by which the next number in the sequence is generated shouldn’t be obvious or predictable. For example, consider the following PRNG algorithm: num = num + 1. This PRNG is perfectly uniform, but it’s not very useful as a sequence of random numbers!

Third, the PRNG should have a good dimensional distribution of numbers. This means it should return low numbers, middle numbers, and high numbers seemingly at random. A PRNG that returned all low numbers, then all high numbers may be uniform and non-predictable, but it’s still going to lead to biased results, particularly if the number of random numbers you actually use is small.

Fourth, all PRNGs are periodic, which means that at some point the sequence of numbers generated will eventually begin to repeat itself. As mentioned before, PRNGs are deterministic, and given an input number, a PRNG will produce the same output number every time. Consider what happens when a PRNG generates a number it has previously generated. From that point forward, it will begin to duplicate the sequence between the first occurrence of that number and the next occurrence of that number over and over. The length of this sequence is known as the period.

For example, here are the first 100 numbers generated from a PRNG with poor periodicity:

112	9	130	97	64	
31	152	119	86	53	
20	141	108	75	42	
9	130	97	64	31	
152	119	86	53	20	
141	108	75	42	9	
130	97	64	31	152	
119	86	53	20	141	
108	75	42	9	130	
97	64	31	152	119	
86	53	20	141	108	
75	42	9	130	97	
64	31	152	119	86	
53	20	141	108	75	
42	9	130	97	64	
31	152	119	86	53	
20	141	108	75	42	
9	130	97	64	31	
152	119	86	53	20	
141	108	75	42	9

You will note that it generated 9 as the second number, and 9 again as the 16th number. The PRNG gets stuck generating the sequence in-between these two 9’s repeatedly: 9-130-97-64-31-152-119-86-53-20-141-108-75-42-(repeat).

A good PRNG should have a long period for all seed numbers. Designing an algorithm that meets this property can be extremely difficult -- most PRNGs will have long periods for some seeds and short periods for others. If the user happens to pick a seed that has a short period, then the PRNG won’t be doing a good job.

Despite the difficulty in designing algorithms that meet all of these criteria, a lot of research has been done in this area because of its importance to scientific computing.

std::rand() is a mediocre PRNG

The algorithm used to implement std::rand() can vary from compiler to compiler, leading to results that may not be consistent across compilers. Most implementations of rand() use a method called a Linear Congruential Generator (LCG). If you have a look at the first example in this lesson, you’ll note that it’s actually a LCG, though one with intentionally picked poor constants. LCGs tend to have shortcomings that make them not good choices for most kinds of problems.

One of the main shortcomings of rand() is that RAND_MAX is usually set to 32767 (essentially 15-bits). This means if you want to generate numbers over a larger range (e.g. 32-bit integers), rand() is not suitable. Also, rand() isn’t good if you want to generate random floating point numbers (e.g. between 0.0 and 1.0), which is often useful when doing statistical modelling. Finally, rand() tends to have a relatively short period compared to other algorithms.

That said, rand() is perfectly suitable for learning how to program, and for programs in which a high-quality PRNG is not a necessity.

For applications where a high-quality PRNG is useful, I would recommend Mersenne Twister (or one of its variants), which produces great results and is relatively easy to use. Mersenne Twister was adopted into C++11, and we’ll show how to use it later in this lesson.

Debugging programs that use random numbers

Programs that use random numbers can be difficult to debug because the program may exhibit different behaviors each time it is run. Sometimes it may work, and sometimes it may not. When debugging, it’s helpful to ensure your program executes the same (incorrect) way each time. That way, you can run the program as many times as needed to isolate where the error is.

For this reason, when debugging, it’s a useful technique to set the random seed (via srand) to a specific value (e.g. 0) that causes the erroneous behavior to occur. This will ensure your program generates the same results each time, making debugging easier. Once you’ve found the error, you can seed using the system clock again to start generating randomized results again.

Random numbers in C++11

C++11 added a ton of random number generation functionality to the C++ standard library, including the Mersenne Twister algorithm, as well as generators for different kinds of random distributions (uniform, normal, Poisson, etc…). This is accessed via the <random> header.

Here’s a short example showing how to generate random numbers in C++11 using Mersenne Twister (h/t to user Fernando):

You’ll note that Mersenne Twister generates random 32-bit unsigned integers (not 15-bit integers like std::rand()), giving a lot more range. There’s also a version (std::mt19937_64) for generating 64-bit unsigned integers.

C++11 style random numbers across multiple functions

The above example create a random generator for use within a single function. What happens if we want to use a random number generator in multiple functions?

Although you can create a static local std::mt19937 variable in each function that needs it (static so that it only gets seeded once), it’s a little overkill to have every function that need a random number generator seed and maintain its own local generator. A better option in most cases is to create a global random number generator (inside a namespace!). Remember how we told you to avoid non-const global variables? This is an exception (also note: std::rand() and std::srand() access a global object, so there’s precedent for this).

Using a random library

A perhaps better solution is to use a 3rd party library that handles all of this stuff for you, such as the header-only Effolkronium’s random library. You simply add the header to your project, #include it, and then you can start generating random numbers via Random::get(min, max).

Here’s the above program using Effolkronium’s library:

Help! My random number generator is generating the same sequence of random numbers!

If your random number generator is generating the same sequence of random numbers every time your program is run, you probably didn’t seed it properly. Make sure you’re seeding it with a value that changes each time the program is run (like std::time(nullptr)).

Help! My random number generator always generates the same first number!

The implementation of rand() in Visual Studio and a few other compilers has a flaw -- the first random number generated doesn’t change much for similar seed values. This means that when using std::time(nullptr) to seed your random number generator, the first result from rand() won’t change much in successive runs. However, the results of successive calls to rand() aren’t impacted, and will be sufficiently randomized.

The solution here, and a good rule of thumb in general, is to discard the first random number generated from the random number generator.

Help! My random number generator isn’t generating random numbers at all!

If your random number generator is generating the same number every time you ask it for a random number, then you are probably either reseeding the random number generator before generating a random number, or you’re creating a new random generator for each random number.

Here’s are two functions that exhibit the issue:

In both cases, the random number generator is being seeded each time before a random number is generated. This will cause a similar number to be generated each time.

In the top case, srand() is reseeding the built-in random number generator before rand() is called (by getRandomNumber()).

In the bottom case, we’re creating a new Mersenne Twister, seeding it, generating a single random number, and then destroying it.

For best results, you should only seed a random number generator once (generally at program initialization for srand(), or the point of creation for other random number generators), and then use that same random number generator for each successive random number generated.

5.10 -- std::cin, extraction, and dealing with invalid text input
Index
5.8 -- Break and continue

364 comments to 5.9 — Random number generation

  • hiep

    Hi everyone!
    I have 2 question on this code, please help me out.
    1/  when I loop it 4 times with the range of (6,19), I always get 9 in the first iteration. Is it because my seed change over the time by minute but not by second ?
    2/  in this code ; static const double faction = 1 / (RAND_MAX + 1.0) . If I change 1.0 to 1, the random numbers generated always are the min. Can you explain to me why ?
    Thank you for your kindness

    • * Line 18, 7: Initialize your variables with brace initializers. Doing so will prevent you from using an int.
      * Line 14: Use std::rand instead of its global-namespaced counterpart.
      * Don't use @system, it won't work on other operating systems.
      * Use ++prefix unless you need postifx++.
      * @fraction should be constexpr.
      * Use single quotation marks for chars.

      > I always get 9 in the first iteration
      I don't know what's going on there. I can't reproduce it. @std::time returns the time in seconds.

      > If I change 1.0 to 1
      1.0 is a double, 1 is an int. Revisit lesson O.3.2.
      Use the literals of the same type you want in the end, unless you need a different precision.

      • hiep

        thank you nascardriver for pointing out my mistake.
        Is there any way to get notification to my email whenever I have a comment on my post sir ?
        Thanks a lot

        • Alex

          Use your real email address when you make your original post. If anyone responds, you'll get an email notification.

          • kwan

            yes sir, I did use my real email address but I still do not get any notification. I also wrote a comment under different email to my post to see if there is any notification sent to my original email

  • Jonas

    Hi!

    Is there any reason for me to use std::time(nullptr) instead of std::time(0) even if my compiler is post-c++11?

    Best regards.

  • James

    what are threads, sir?
    and what does it mean to be thread safe?

    • Threads allow you to run code in parallel. Right now, your code can only be executing in one place at a time.

      Let's say you have 1 sweeper (1 Thread), you can sweep a parking lot (do some task) just fine.
      If you add another sweeper (Thread) , you can sweep the parking lot (finish the task) quicker, nice!
      If you add too many sweepers (Threads), the parking lot (Task) will get crowded and you might slow down the work, not so nice.

      The sweepers (Threads) have to empty their tanks (Access some variable) at some point, but there's only 1 dumping site.
      If 2 sweepers (Threads) try to empty their tank (Access the variable) at the same time, they'll crash, ie. access to the dumping site (variable) is not thread safe.
      You could add a traffic light (lock guard) to the dumping site, so that only 1 sweeper (thread) can visit it at a time. Now accessing the dumping site (variable) is thread safe.

      • James

        aren't are programs only access the variables one after another? I can't put it together with the codes we've been writing so far. Any example?

        • Threads aren't covered by learncpp yet, and understanding them just now might be too much to ask for. Anyway, here's an example https://en.cppreference.com/w/cpp/thread/lock_guard

  • James

    By "modulus tends to be biased in favor of low numbers", I don't think the example given is what being biased mean.
    Since we're getting *random number from rand(), not a sequence, the example given has nothing do with being biased. You'll get the same amount of higher and lower number using both methods(although vary a bit), so getting more lower numbers with modulus is not relevant here.
    Modulus is biased in favor of low numbers in a way that only min and max of lower than RAND_MAX can be used.
    If you put higher numbers than RAND_MAX, modulus program will be broken while fraction program is still fine.
    Here's the code I tested it with-

    • Alex

      I think you may have misunderstood the intent of the explanation. When you use the modulus method (even for a single number) there's a higher chance that a lower number will be returned than a higher one. That's the definition of a biased result. It's like rolling a die that's slightly loaded towards 1.

      • James

        Sorry for bothering you with bizarre questions, I retested it again and got like 65-80% of the time getting more lower number with modulus while 30 to 40 with fraction using the below code. You can simply build and run this if you don't want to check my messed up code or see if you can give any advise to your pupil on his coding. This checks 1 million random numbers between min 1 and max 50(both inclusive) any number of times user input.
        Since using system time as seed would be redundant if the process ran twice or more within the same second, I made the user in put 2 integers for seeding to test it with different seeds. And please help me figure out how to find the period of an RNG. I'm having different result depending on how many same numbers I try to test. The more same number I test the longer the period become.

  • User

    I'd like to ask why did you cast the time function from <ctime> as an unsigned integer, because I printed the result without casting it & the two results were identical.

    • Have a look at
      https://en.cppreference.com/w/cpp/numeric/random/srand
      https://en.cppreference.com/w/cpp/chrono/c/time
      @std::time returns an @std::time_t, which is an implementation-defined type.
      @std::srand wants an unsinged int as its argument.
      Omitting the cast will only work if @std::time_t can implicitly be cast to unsigned int, this might not be the case on all systems.

  • Red Lightning

    I did not understand something in here, if the std::rand() returns 0, then std::rand() * fraction will be 0 (multiplication by 0 returns 0), and if that will be 0, then (max - min + 1) * (std::rand() * fraction) will be 0, because it will be equivalent to (max - min + 1) * 0 which is 0.

    I have noticed that in the explanation it was written that we add min, which would then turn the 0 to min, which is okay. But in the example there was no addition with min.

  • Alireza

    Hi there,

    Question: How does the function @rand() takes the seed variable for the first time without using @srand() function ?
    I know it returns the same random numbers when we run it again and again; but how does it do for the first time ?
    Just using :

  • Hi Alex!

    @std::mt19937's parameter is an @std::uint_fast32_t, not an unsigned int.
    To be safe, @std::mt19937::result_type should be used.
    To be compatible with an upgrade to @std::mt19937_64, @decltype(mersenne)::result_type should be used.

  • Paulo Filipe

    Well, I am really enjoying to play with Random Numbers, and the different ways of seeding the Mersenne Twister.
    What do you guys think of the idea of performing some weird calculation between, say, Chrono time and Ctime time, to create a even better random seed??

    • Hi Paulo!

      * Line 25, 26, 27: Initialize your variables with brace initializers. You used direct initialization.
      * Don't use @std::(u)int*_t, it's not guaranteed to exist. Use @std::(u)int_least*_t or @std::(u)int_fast*_t.

      Nice to see that you found something that keeps you motivated!
      The problem with using @std::time as a seed is that it's easily predictable. An attacker would only need the current time in seconds to reproduce your program's "random" numbers.
      Using chrono's high resolution clock makes this harder, as it's changing extremely fast.
      An attacker can reproduce all your calculations (Assuming they have access to the source or binary). The only difficulty is getting the same seed, because it is determined at run-time.
      Adding @std::time to the seed doesn't help. If the attacker knew it before, they know it now and they can reproduce the calculation.

      • Paulo Filipe

        So, to clear the (u)int*_t type. From what I've searched online, this type is exactly 32 bits, if an architecture doesn't have a type of exactly 32 bits, this type will never exists. Using (u)int_least*_t or (u)int_fast*_t can be any type of at least * bits meaning that an architecture that doesn't have a type of exactly * bits can create any type that satisfies at least * bytes, with least favoring the smallest type possible and fast favoring the fastest type possible.

        Is this statement correct?

    • Alex

      There's no added randomization in seeding a random number generator with a random value from another RNG. This is because the values from a RNG aren't actually random, they're deterministic mathematical transformations of the seed value. If you knew the formula, you could deterministically calculate them yourself -- and given that, you're not adding any randomness in the process over using the original seed value.

  • Paulo Filipe

    @Alex @nascardriver,
    I've done some googling about RNGs and I've came across easier ways of building RNGs using std::random_device.

    Is there any major disadvantage in using std::random_device as the generator as my example:

    Or even using std::random_device to seed the Mersenne Twister as follow:

    Also, these methods use exclusively the Random library thus not requiring to #include more stuff.

    I created these examples with the Hi-Lo quizz needs in mind.

    Can you guys enum some advantages / disadvantages of this kind of method against the Ctime library method of seeding the RNG?

    Thanks in advance, and as always, loving you guys effort in passing us this knowledge.

    PS: It's because of discussions like this that I suggested you guys to create a discord server. :) everybody could share their thoughts.

    • Snippet 1
      * Line 6, 7: Initialize your variables with brace initializers.

      Snippet 2
      * Line 6, 7, 8: Initialize your variables with brace initializers.

      @std::random_device was part of this lesson once. It was removed, because it only works if a non-deterministic source (Hardware noise or similar) is a available. If no such source exists, @std::random_device generates the same number sequence every time, making it equivalent to using no seed at all.

      • Paulo Filipe

        Could you elaborate on that please? Perhaps pointing me to a good read?

        • Quoting the standard n4800 § 25.6.6
          1 A random_device uniform random bit generator produces nondeterministic random numbers.
          2 If implementation limitations prevent generating nondeterministic random numbers, the implementation may employ a random number engine.

          A "random number engine" is deterministic (§ 25.6.2.4).
          Some Unix implementations use /dev/urandom as a non-deterministic source ( https://en.wikipedia.org/wiki//dev/random ).

        • Paulo Filipe

          Edit: I found an interesting article:

          http://www.pcg-random.org/posts/simple-portable-cpp-seed-entropy.html

          The Chrono library looks even better than the Ctime. :)

  • ethano

    under the code in the "Random Numbers In C++11" section, the sentence is incomplete. "There’s also a version (std::mt19937_64) for generating 64-bit unsigned" is literally what it says, just recommending you add like " integers." to that.

  • Florean

    Hi, Thank you for this great structured top notch tutorial..
    When I read about random seeds first thing that came into my mind was: Why not use a random piece of memory, such as when initialising an uint without assigning a value..

    const uint randomValue;
    std::cout << randomValue; // prints whatever is found in that piece of memory

    Or are there compiler-wise behaviour problems? Xcode does it well.

    Cheers :)

    • Alex

      The value of an uninitialized variable is undefined. The value could be anything, and may change every time you run the program or not at all. And because it's not reliable, it shouldn't be used as a seed.

      • Florean

        Thank you for your reply, Alex. Obviously I'm ignorant of the memory usage mechanics of a computer, just thought that whatever bit-combination is found in that newly assigned piece of memory can in the end also be interpreted as a number, so why not use this real randomness (undefined = random?). I find this interesting and will read more on how the memory management behind the scenes really works; by then I'd follow your advice.

  • Barne

    @Alex

    Doing the chapter 6 quiz, made me realise that the mersenne section could have been a bit clearer.
    I'd like to suggest you showing us how to use the mersenne with functions, and what needs to be passed and how. The last section shows us how not to do it, but just moving the seeding to main() obviously doesn't work (maybe you're supposed to pass it as a parameter?). Should you declare the int_distribution and pass that too?

    Cheers for the guide so far!

  • A way I used to "cheat" a little to make random numbers really random in games, is by adding a few calls to the "random" function that would just go off in every 'cycle' the game goes through. This could basically only generate the same number if the user could have perfect timing in how to play, but since no human being can do that, things worked out that way. It's a dirty trick, but for me it was the result that counted, rather than the way it was produced :P

  • NXPY

    return min + static_cast<int>((max - min + 1) * (std::rand() * fraction));
    }
    If std::rand()*fraction always give a value between 0 and 1 , won't it be biased towards low numbers ?
    For example if std::rand() gives 6 and rand_max is 9 .Then their product would be 0.6
    If max-min+1 is 6 , then value is 3.6 which is 3 .

  • Estelyen

    I tried using mt19937_64 but unfortunately std::uniform_int_distribution<> won't allow me to pass any number higher than a signed 32bit int as a range parameter.

    How should I go about getting higher random numbers?

    • Those empty triangle brackets take a type as parameter. They default to int. You can pass any built-in int type (But not @std::int_least64_t or similar!), eg. long long. Doing so allows your parameters to have a different range than the default int.

  • Ajalle Perfej

    I finally got motivated to try the hi-lo guessing game from the end of chapter exercises and am already stuck. Here's the code and then the error message:

    random.cpp

    test.cpp

    error:

    It must be some minor stupid typo but I can't find it. Please help.

Leave a Comment

Put all code inside code tags: [code]your code here[/code]