For 6 years I've had a random number generator page on my website. For a long time, it was the first or second result on Google for "random number generator" and has been used to decide dozens, if not hundreds of contests and drawings on discussion forums and blogs (I know because I see the referrers in my web logs and usually go take a look).
Today, someone emailed me to tell me it may not be as random as I thought. She tried generating very large random numbers (e.g., between 1 and 10000000000000000000) and found that they were almost always the same number of digits. Indeed, I wrapped the function in a loop so I could generate thousands of numbers and sure enough, for very large numbers, the variation was only about 2 orders of magnitude.
Why?
Here is the looping version, so you can try it out for yourself:
http://andrew.hedges.name/experiments/random/randomness.html
It includes both a straightforward implementation taken from the Mozilla Developer Network and some code from 1997 that I swiped off a web page that no longer exists (Paul Houle's "Central Randomizer 1.3"). View source to see how each method works.
I've read here and elsewhere about Mersenne Twister. What I'm interested in is why there wouldn't be greater variation in the results from JavaScript's built-in Math.random function. Thanks!
Given numbers between 1 and 100.
Given numbers between 1 and 1000.
and so on.
So if you select some at random, then that vast majority of selected numbers will have the same number of digits, because the vast majority of possible values have the same number of digits.
There different types of randomness. Math.random gives you an uniform distribution of numbers.
If you want different orders of magnitude, I would suggest using an exponential function to create what's called a power law distribution:
This function should give you roughly the same number of 1-digit numbers as 2-digit numbers and as 3-digit numbers.
There are also other distributions for random numbers like the normal distribution (also called Gaussian distribution).
If you use a number like 10000000000000000000 you're going beyond the accuracy of the datatype Javascript is using. Note that all the numbers generated end in "00".
Looks perfectly random to me! (Hint: It's browser dependent.)
Personally, I think my implementation would be better, although I stole it off from XKCD, who should ALWAYS be acknowledged:
Well, if you are generating numbers up to, say, 1e6, you will hopefully get all numbers with approximately equal probability. That also means that you only have a one in ten chance of getting a number with one digit less. A one in a hundred chance of getting two digits less, etc. I doubt you will see much difference when using another RNG, because you have a uniform distribution across the numbers, not their logarithm.
The following paper explains how math.random() in major Web browsers is (un)secure: "Temporary user tracking in major browsers and Cross-domain information leakage and attacks" by Amid Klein (2008). It's no stronger than typical Java or Windows built-in PRNG functions.
On the other hand, implementing SFMT of the period 2^19937-1 requires 2496 bytes of the internal state maintained for each PRNG sequence. Some people may consider this as unforgivable cost.