5

I'm making a game in C++ and it involves filling tiles with random booleans (either yes or no) whether it is yes or no is decided by rand() % 1. It doesn't feel very random.

I'm using srand with ctime at startup, but it seems like the same patterns are coming up.

Are there any algorithms that will create very random numbers? Or any suggestions on how I could improve rand()?

Bo Persson
  • 90,663
  • 31
  • 146
  • 203
jmasterx
  • 52,639
  • 96
  • 311
  • 557
  • Just out of curiosity how "large" is your array? if its small you might not see much randomness. – GrayWizardx Dec 16 '09 at 04:09
  • Can you show the code? It's possible something is just wonky with the way you're seeding and that's why it appears to have a consistent pattern. – Jim Wallace Dec 16 '09 at 04:09
  • 16
    "rand() % 2" will yield much better results. – Drew Dormann Dec 16 '09 at 04:28
  • 12
    rand() % 1 is usually zero, for sufficiently small values of 1. – Michael Foukarakis Dec 16 '09 at 06:55
  • Humans are notoriously bad at detecting randomness. If it's important then don't guess: once you've fixed the %1 / %2 bug, capture a large number of results (1000s, not 10s), stick them into Excel, and get it to work out the average. – AAT Dec 16 '09 at 13:42

14 Answers14

23

True randomness often doesn't seem very random. Do expect to see odd runs.

But at least one immediate thing you can do to help is to avoid using just the lowest-order bit. To quote Numerical Recipes in C:

If you want to generate a random integer between 1 and 10, you should always do it by using high-order bits, as in
j = 1 + (int) (10.0 * (rand() / (RAND_MAX + 1.0)));
and never by anything resembling
j = 1 + (rand() % 10);
(which uses lower-order bits).

Also, you might consider using a different RNG with better properties instead. The Xorshift algorithm is a nice alternative. It's speedy and compact at just a few lines of C, and should be good enough statistically for nearly any game.

Boojum
  • 6,592
  • 1
  • 30
  • 34
  • 12
    Avoiding low-order bits depends very much on the generator. Some PRNGs generate weak *high-order* bits instead. – Joey Dec 16 '09 at 06:51
8

The low order bits are not very random.
By using %2 you are only checking the bottom bit of the random number.

Assuming you are not needing crypto strength randomness.
Then the following should be OK.

bool  tile = rand() > (RAND_MAX / 2);
Martin York
  • 257,169
  • 86
  • 333
  • 562
  • Actually, by using %1 they're not even using the bottom bit. :) – Drew Dormann Dec 16 '09 at 04:30
  • 4
    Your solution has the same problem as the original one: using only one bit of rand()'s return value. The OP uses only the lowest bit, your solution uses only the highest bit. A better solution would use all bits. – sbk Dec 16 '09 at 10:26
  • @sbk: If I think on it hard yes you are correct. I was just simplifying 'rand()/(RAND_MAX + 1.0) * RANGE' Where the range is 2. – Martin York Dec 29 '09 at 16:04
4

The easiest thing you can do, short of writing another PRNG or using a library, would be to just use all bits that a single call to rand() gives you. Most random number generators can be broken down to a stream of bits which has certain randomness and statistical properties. Individual bits, spaced evenly on that stream, need not have the same properties. Essentially you're throwing away between 14 and 31 bits of pseudo-randomness here.

You can just cache the number generated by a call to rand() and use each bit of it (depending on the number of bits rand() gives you, of course, which will depend on RAND_MAX). So if your RAND_MAX is 32768 you can use the lowest-order 15 bits of that number in sequence. Especially if RAND_MAX is that small you are not dealing with the low-order bits of the generator, so taking bits from the high end doesn't gain you much. For example the Microsoft CRT generates random numbers with the equation

xn + 1 = xn · 214013 + 2531011

and then shifts away the lowest-order 16 bits of that result and restricts it to 15 bits. So no low-order bits from the generator there. This largely holds true for generators where RAND_MAX is as high as 231 but you can't count on that sometimes (so maybe restrict yourself to 16 or 24 bits there, taken from the high-order end).

So, generally, just cache the result of a call to rand() and use the bits of that number in sequence for your application, instead of rand() % 2.

Joey
  • 344,408
  • 85
  • 689
  • 683
3

C++11 has the following way of implementing the Mersenne tittie twister algorothm. From cppreference.com:

#include <random>
#include <iostream>

int main()
{
    std::random_device rd;
    std::mt19937 gen(rd());
    std::uniform_int_distribution<> dis(1, 6);

    for (int n=0; n<10; ++n)
        std::cout << dis(gen) << ' ';
    std::cout << '\n';
}

This produces random numbers suitable for simulations without the disadvantages of many other random number generators. It is not suitable for cryptography; but cryptographic random number generators are more computationally intensive.

There is also the Well equidistributed long-period linear algorithm; with many example implementations.

CodeLurker
  • 31
  • 2
3

Many pseudo-random number generators suffer from cyclical lower bits, especially linear congruential algorithms, which are typically the most common implementations. Some people suggest shifting out the least significant bits to solve this.

David R Tribble
  • 11,918
  • 5
  • 42
  • 52
2

Boost Random Number Library

oz10
  • 153,307
  • 27
  • 93
  • 128
2

I have used the Mersenne Twister random number generator successfully for many years. Its source code is available from the maths department of Hiroshima Uni here. (Direct link so you don't have to read Japanese!)

What is great about this algorithm is that:

  1. Its 'randomness' is very good
  2. Its state vector is a vector of unsigned ints and an index, so it is very easy to save its state, reload its state, and resume a pseudo-random process from where it left off.

I'd recommend giving it a look for your game.

mcdave
  • 2,550
  • 17
  • 22
  • Show me any PRNG where the second quoted advantage *doesn't* hold. That's pretty much a standard feature of PRNGs, actually. – Joey Dec 16 '09 at 06:53
1

The perfect way of Yes or No as random is toggling those. You may not need random function.

YOU
  • 120,166
  • 34
  • 186
  • 219
1

The lowest bits of standard random number generators aren't very random, this is a well known problem.

I'd look into the boost random number library.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
0

A quick thing that might make your numbers feel a bit more random would be to re-seed the generator each time the condition if(rand() % 50==0) is true.

Tom Neyland
  • 6,860
  • 2
  • 36
  • 52
  • 2
    What ... exactly does that condition tell you about the need to re-seed? – Joey Dec 16 '09 at 07:58
  • Depending on the range of the numbers being generated, and the number generator, it will *(should)* automatically re-seed the generator 1 out of every 50 (or whatever) numbers generated – Tom Neyland Dec 16 '09 at 17:53
  • Note that "feel more random" does not equal better statistical randomness properties. PRNGs are fickle things, especially when treated improperly or without very precise knowledge what one is doing (and even then they can explode back into your face). – Joey Dec 17 '09 at 10:41
0

People say lower-order bits are not random. So try something from the middle. This will get you the 28th bit:

(rand() >> 13) % 2
Claudiu
  • 224,032
  • 165
  • 485
  • 680
0

Knuth suggests a Random number generation by subtractive method. Its is believed to be quite randome. For a sample implementation in the Scheme language see here

  • 1
    As good a book as TAoCp is, that one is pretty dated and *a lot* has happened in PRNG research in the past 20 years. The subtractive method isn't much better than an LCG, actually. – Joey Dec 16 '09 at 06:55
-1

With random numbers to get good results you really need to have a generator that combines several generators's results. Just discarding the bottom bit is a pretty silly answer.

multiply with carry is simple to implement and has good results on its own and if you have several of them and combine the results you will get extremely good results. It also doesn't require much memory and is very fast.

  • 1
    You don't need to combine generators to get good results, you just need to use a good generator. Also, combining generators without knowing what you are doing is likely to produce poor results. – Steve S May 26 '10 at 16:54
-2

Also if you reseed too fast then you will get the exact same number. Personally I use a class that updates the seed only when the time has changed.

user230821
  • 1,093
  • 3
  • 12
  • 21
  • It's less random if you don't reseed. – user230821 Dec 16 '09 at 04:47
  • 3
    Its NOT random if you re-seed. – Martin York Dec 16 '09 at 04:48
  • rand() goes through a sequence designed to be random (sort of), as long as you keep going. If you re-seed then you start a new sequence. There are no guarantees about the relationship of the two sequences. – Martin York Dec 16 '09 at 04:50
  • If you reseed with the same number martin then ya. I am talking about reseeding with the time when it is different. – user230821 Dec 16 '09 at 04:52
  • 1
    @high6: No. That is exactly what I am talking about. You seed once when the application starts then you don't re-seed again. Otherwise you are defeating the purpose of the seed. To start a random sequence. – Martin York Dec 16 '09 at 04:58
  • If you never reseed then it is even less random. – user230821 Dec 16 '09 at 05:15
  • Please note you are already on -2. The reason it seems closer to my number is that you are actually only re-seeding about 4 times (depending on the speed of your processor). The more you re-seed the less random it becomes. And digging further. Your new example is even worse. GetTickCount() repeats every 49 days and thus is not a good seed for random. So not only are you numbers random or evenly distributed your are seriously jeopardy of repeating a sequence. time() on the other hand only repeats every 60 years. – Martin York Dec 16 '09 at 07:52
  • Actually, if you are drawing *lots* of numbers you have to re-seed eventually, especially if you are exhausting the numeric range of the PRNG return type. Generating pseudo-random numbers is actually drawing balls from a bowl *without putting them back.* So if you use very large amounts of numbers (or, for some PRNGs not so large ones) you are hurting your randomness. Still, updating the seed periodically is a Bad Idea™ as then yuo'll get a linear dependence of the seeds which hurts your randomness even more. You can re-seed if you're something like halfway through the period of the PRNG. – Joey Dec 16 '09 at 07:53
  • This whole discussion just proves that random is not a trivial subject. Unless you really know what you are doing you should be using libraries that do the work for you. Please take a look at the boost random libraries. – Martin York Dec 16 '09 at 07:54
  • @Johannes: Very true. But that's way beyond this discussion. – Martin York Dec 16 '09 at 08:00
  • Martin: Agreed :-) Still, not all "rules" how to treat PRNGs apply in every case :-) – Joey Dec 16 '09 at 08:09
  • Yup, because being -2 means you are instantly wrong no matter what. Anyways, thanks for at least explaining it Johannes. I get what you mean. Although wouldn't that depend on the random algorithm being used? – user230821 Dec 16 '09 at 16:27
  • It *always* depends on the algorithm. As Martin already said, pseudo-random numbers are not trivial and re-seeding blindly without knowing what *exactly* you're doing will very likely hurt you. The problem is, that unless something goes *catastrophically* wrong you won't notice that your output is flawed. Re-seeding every second should be such a case. There are numerous papers on that subject, too. And still, I think the −2 is appropriate here (even though I didn't downvote). The advice *is* bad. I just noted that blindly recommending never to re-seed doesn't work in the general case too. – Joey Dec 17 '09 at 10:40