I am using rand() to generate either 0 or 1 (rand() % 2). I am seeding it using the current time (srand(time(NULL))).
After much debugging, I realised that rand() never returns an even (odd) number 16 or more times in a row.
Is this a known issue? Is there a better PRNG that comes with C?
I am running on Windows 7 using Visual Studio 2010.
Instead of using rand()%2, try rand()>(RAND_MAX/2). You can only assume rand() to be uniform on the interval [0, RAND_MAX].
Edit: This was suggested by Shahbaz in the comments, which I only noticed after I posted this answer.
Edit: ArjunShankar called me out on my previous wording: "rand() is only specified to be uniform on the interval [0, RAND_MAX]"
From the C99 standard:
The rand function computes a sequence of pseudo-random integers in the range 0 to
RAND_MAX.
Technically, uniformity (or equidistributed) is not specified, but is the de-facto standard used for implementations of commonly used PRNG's (e.g. Mersenne Twister). This is to allow a programmer to easily create a custom PRNG with a non-uniform distribution. Without this property, a programmer is forced to implement a custom PRNG from scratch.
I'd suggest using a better RNG. You're running on Windows so you can use rand_s: It's a Microsoft extension that uses the Windows cryptographic RNG.
rand() is well-known to suck. random() is a bit better (sometimes), but drand48() and its family are much better.
In you need better than that, look into the mersene twister or other PRNG libraries. Or check out /dev/random if that can provide enough data for your needs.
Well, You can use Algorithms for Mersenne Twister or WELL. The code for WELL is on here(I don't have enough reputations)
http://i.stack.imgur.com/q6VPL.png
Related
Is it acceptable to use the C standard library's rand() function for random numbers that do not have to be cryptographically secure? If so, are there still better choices? If not, what should be used?
Of course, I assume the usual caveats about skew apply.
rand() suffers from some serious drawbacks.
There is no guarantee on the quality of the random number. This will vary from implementation to implementation.
The shared state used by different calls to rand, is not guaranteed to be thread safe.
As for POSIX C alternatives, there is random and random_r. OpenSSL provides more advances ways of generating random numbers.
The C++ (C++11 and later) library also provides a number of random number functions if including C++ in your project is an option.
Cryptographic security aside, there are a lot of systems where rand() has pretty atrocious randomness properties, and the standard advice if you need something better is to use the non-Standard random().
rand's poor properties on many systems include:
nonrandomness in the low-order bits (such that e.g. rand()%2 is guaranteed to alternate 0,1,0,1...).
relatively short period, perhaps "only" 4 billion or so
So my (reluctant) advice is that if you need "good" randomness (say, for a Monte Carlo simulation), you may very well want to investigate using a nonstandard alternative to rand(). (One of my eternal questions about C is why any vendor would spend time deploying a nonstandard random() instead of simply making rand() better. And I do know the canonical answers, although they suck.)
See also this similar question.
Yes, it is fine to use rand() to get pseudo-random numbers. In fact, that is the whole point of rand(). For simple tasks, where it is OK to be deterministic, you can even seed the system clock for simplicity.
The implementation of rand in mainstream C standard libraries may be adequate for casual use of pseudorandom numbers (such as in most single-player games, or for aesthetic purposes), especially if your application doesn't care about repeatable "randomness" across time or across computers. (But note that the rand specification in the C standard doesn't specify a particular distribution that the numbers delivered by rand have to follow.)
However, for more serious use of pseudorandom numbers, such as in a scientific simulation, I refer you to another answer of mine, where I explain that the problem with rand/srand is that rand—
Uses an unspecified RNG algorithm, yet
allows that RNG to be initialized with srand for repeatable "randomness".
These two points, taken together, hamper the ability of implementations to improve on the RNG's implementation; changing that RNG will defeat the goal of repeatable "randomness", especially if an application upgrades to a newer version of the C runtime library by the same vendor or is compiled with library implementations by different vendors. The first point also means that no particular quality of pseudorandom numbers is guaranteed. Another problem is that srand allows for only relatively small seeds — namely those with the same size as an unsigned.
However, even if the application doesn't care about repeatable "randomness", the fact that rand specifies that it behaves by default as though srand(1) were called (and thus, in practice, generates the same pseudorandom sequence by default) makes using rand harder to use effectively than it could be.
A better approach for noncryptographic pseudorandom numbers is to use a PRNG library—
that uses self-contained PRNGs that maintain their own state (e.g., in a single struct) and don't touch global state, and
that implements a PRNG algorithm whose details are known to the application.
I list several examples of high-quality PRNG algorithms for noncryptographic pseudorandom numbers.
I want to generate uncorrelated random number to do a simulation... However, the numbers generated by the rand() function in the C language are correlated. Is there any possibility to use the rand() function and generate multiple random streams? I mean, if the rand() function generate for me a series of correlated numbers, can I cut this series into different streams. Then use these streams independently?
Thanks
You are indeed correct. They are normally autocorrelated as the normal generator implementation is linear congruential (although the C standard does not mandate this). As such an x-y plot of successive numbers will fail a chi square test for random 2D dispersion.
Depending on your application, you could look at Bays-Durham shuffle which, to my knowledge, passes the diehard test for randomness: it's aim is to defeat autocorrelation effects.
I direct you to www.nr.com for an implementation and the rand1, rand2 functions in particular. A more modern way is to use a mersenne twister scheme but a little tricker to implement (by the way C++11 has this generator as part of its standard library).
If your C implementation has rand_r, you can try that. It lets you specify a location to store the state.
Or just use your own pseudo-random number generator.
You may use arc4random or better ar4random_uniform to increase randomness of generated values (actually ar4random_uniform proves you uniformly distributed values).
Generating true random numbers on a computer is impossible, you can only generate "pseudo-random" numbers i.e. numbers that "looks like" random.
Usually one will use a ''seed'' (small sequence of bits) with enough entropy and then "expand" it thanks to a Pseudo-Random-Number-Generator.
C rand() function generates poor quality of randomness, try PRNG that have been proposed in other answers/comments. Some examples:
Mersenne Twister (widely used)
ANSI X9 (adopted by FIPS standard)
I am using rand() to generate either 0 or 1 (rand() % 2). I am seeding it using the current time (srand(time(NULL))).
After much debugging, I realised that rand() never returns an even (odd) number 16 or more times in a row.
Is this a known issue? Is there a better PRNG that comes with C?
I am running on Windows 7 using Visual Studio 2010.
Instead of using rand()%2, try rand()>(RAND_MAX/2). You can only assume rand() to be uniform on the interval [0, RAND_MAX].
Edit: This was suggested by Shahbaz in the comments, which I only noticed after I posted this answer.
Edit: ArjunShankar called me out on my previous wording: "rand() is only specified to be uniform on the interval [0, RAND_MAX]"
From the C99 standard:
The rand function computes a sequence of pseudo-random integers in the range 0 to
RAND_MAX.
Technically, uniformity (or equidistributed) is not specified, but is the de-facto standard used for implementations of commonly used PRNG's (e.g. Mersenne Twister). This is to allow a programmer to easily create a custom PRNG with a non-uniform distribution. Without this property, a programmer is forced to implement a custom PRNG from scratch.
I'd suggest using a better RNG. You're running on Windows so you can use rand_s: It's a Microsoft extension that uses the Windows cryptographic RNG.
rand() is well-known to suck. random() is a bit better (sometimes), but drand48() and its family are much better.
In you need better than that, look into the mersene twister or other PRNG libraries. Or check out /dev/random if that can provide enough data for your needs.
Well, You can use Algorithms for Mersenne Twister or WELL. The code for WELL is on here(I don't have enough reputations)
http://i.stack.imgur.com/q6VPL.png
As far as I know rand() does not generate a uniform random distribution. What function/algorithm will allow me to do so? I have no need for cryptographic randomness, only a uniform random distribution. Lastly, what libraries provide these functions?
Thanks!
rand() does generate a uniform (pseudo-)random distribution.
The actual requirement, from the C standard (3.7 MB PDF), section 7.20.2.1, is:
The rand function computes a sequence of pseudo-random integers in
the range 0 to RAND_MAX.
where RAND_MAX is at least 32767. That's admittedly vague, but the intent is that it gives you a uniform distribution -- and in practice, that's what implementations actually do.
The standard provides a sample implementation, but C implementations aren't required to use it.
In practice, there are certainly better random number generators out there. And one specific requirement for rand() is that it must produce exactly the same sequence of numbers for a given seed (argument to srand()). Your description doesn't indicate that that would be a problem for you.
One problem is that rand() gives you uniformly distributed numbers in a fixed range. If you want numbers in a different range, you have to do some extra work. For example, if RAND_MAX is 32767, then rand() can produce 32768 distinct values; you can't get random numbers in the range 0..9 without discarding some values, since there's no way to evenly distribute those 32768 distinct values into 10 equal sized buckets.
Other PRNGs are likely to give you better results than rand(), but they're still probably going to be subject to the same issues.
As usual, the comp.lang.c FAQ answers this better than I did; see questions 13.15 through 13.21.
Here's an article and a stand-alone random number generator written in C#. The code is very small and easily portable to C++ etc.
Whenever this subject comes up, someone responds that you should not use your own random number generator but should leave that up to specialists. I respond that you should not come up with your own algorithm. Leave that up to specialists because it is indeed very subtle. But it's OK and even beneficial to have your own implementation. That way you know what's being done, and you could use the same method across languages or platforms.
The algorithm in that article is by George Marsaglia, a top expert in random number generation. Even though the code is tiny, the method holds up well to standard tests.
The BSD random() function (included in the XSI option of POSIX/SUS) is almost universally available and much better than rand on most systems (except some where rand actually uses random and thus they're both pretty good).
If you'd rather go outside the system libraries, here's some good information on your choices:
http://guru.multimedia.cx/category/pseudo-random-number-generators/
(From Michael Niedermayer of FFmpeg fame.)
Well, the question of whether or not an actual pseudorandom generator exists is still open. That being said, a quick search reveals that there may be some slightly better alternatives.
I am trying to code a random number generation function in embedded C where I can't include the math.h file. Thats why I'm not able to use the seed srand function.
Is there any other way to seed it other than time?
Consider using the Mersenne Twister, sources are e.g. here -- much higher quality than traditional linear congruential generators, superbly long period, deeply studied in, and blessed by, plenty of recent academic literature.
srand is in stdlib.h, not math.h. To seed with time you include time.h to use time(NULL), not math.h. I don't see how it's relevant.
If rand and srand are not available, you can create one your own, e.g. LCG or Mersenne twister.
If speed and security is not a concern, you can store the current PRNG state in persistent memory and restart from that point when a random number is required. For instance, MT19937 has period of 219937 - 1 which should be enough for normal purpose when without reseeding.
If seeding is really required, anything that is not constant in any scales can be used as the seed.
Consider having a looksee through this lecture, might give you some ideas (and code).
The pdf goes through a few different options, and even gives a bit of code.
I am trying to code a random number generation function in embedded C where I can't include the math.h file. Thats why I'm not able to use the seed srand function.
srand() is commonly seeded using time(), and that is defined in <time.h>, not in <math.h>.
Is there any other way to seed it other than time?
Of course, you can seed it with anything you want. It depends on your platform what is available.