Imagine we have two independent pseudo-random number generators using same algorithm but seeded differently. And we are generating numbers of same size using these generators, say 32-bit integers. Provided algorithm gives us uniform distribution, there is 1/2^32 probability (or is it?) of a collision. If a collision just happened, what is the probability the very next pair will also be a collision? It seems for me this probability might be different (higher) from that initial uniform-based collision chance. Most of currently existing pseudo-random number generators hold internal state to maintain own stability, and recently happened collision might signal those internal states are somewhat "entangled" giving modified (higher) chance of a collision to happen again.
The question is probably too broad to give any precise answer, but revealing general directions/trends could also be nice. Here are some interesting aspects:
Does size of initial collision matter? Is there a difference after a
collision of 8 consecutive bits vs 64 bits? How approximately chance
of next collision depends on size of generated sequence?
Does pattern of pair generation matter? For example, we could find
initial collision by executing first generator only once and
"searching" second generator. Or we could invoke each generator on
every iteration.
I'm particularly interested in default javascript Math.random().
32-bit integers can be generated of that like
this (for example). EDIT: As pointed in comments, conversion of
random value from [0; 1) range should be done carefully, as exponent of
such values is very likely to repeat (and it takes decent part of result
extracted this way).
I have some logic within a function that takes a string of numbers called digits like so:
6145390195186705543
I then attempt to convert with parseInt() like so:
parseInt(digits)
The result of:
digits = parseInt(digits);
is
6145390195186705000
Can someone help me understand why this is the case? and how i can get an accurate conversion?
This is another version of "broken" floating point math: Javascript uses 64 bits to store numbers as small as the size of an atom up to the number of atoms in the universe. As that is quite a broad range it cannot be stored accurately, therefore the numbers are stored in an imprecise way but can represent a very broad range. In your case 6145390195186705000 is the inaccurate version JS is able to store as 6145390195186705543 cannot be stored.
and how i can get an accurate conversion?
You cannot store an "accurate number", therefore you cannot convert it accurately. However there are some libraries that allow you to work with strings as if they were numbers, such as BigIntJS.
As this is a common problem, this is going to be solved in the next JS version, see this proposal. You can currently test it in the new version of chrome.
I am interested in finding out which seeds are used for native random number generators in common languages. Primarily, it's Javascript, Objective C, Swift and Java.
If you want to generate unique ids in distributed systems, you want to minimise the risk of collision. One strategy is to use a UNIX timestamp concatenated with a random number. However, if UNIX timestamp is also used as the sole seed for the random number generator, there is no point in adding a random number to the timestamp. If two units calculated an id at the same time using the same pseudo-random generator, they would then return the same random number as well. Using a hardware-specific id as part of the seed would be a good strategy, I think. But how is it actually implemented already in these languages?
This is a platform/framework question, not a language question.
I would suggest generating a UUID on all platforms. UUIDs are designed to be completely unique. iOS/Mac OS has NSUUID. I don't know about the other platforms.
I am writing some code that shall run in a browser, which uses Javascript random function(s) for key generation.
Now reading in several forums that this is considered to be not secure, due to bad random number generation.
Now, what if I only create one key pair per browser/computer. So, having a distributed scenario where there is actually no sequence of random numbers per browser. Will this fundamentally change the problematic situation? Thanks for your thoughts.
Yes it matters. If an attacker generates random numbers at the same time as a genuine user, they can predict what is generated and retrieve they key. Even if the clocks aren't fully synchronised, an attacker could generate a range around the UNIX timestamp when the key was known to have been generated and then try each one in turn.
Solution: Use window.crypto to generate a secure random number using the crypto library.
The Crypto interface represents basic cryptography features available
in the current context. It allows access to a cryptographically strong
random number generator and to cryptographic primitives.
Random numbers are generated in Javascript by the amount of milliseconds since 1st of January 1970(UNIX Timestamp). Then Javascript just takes the first few values and that is your random number. i.e.
Math.floor((Math.random() * 10) + 1);
Makes a random number between 1 and 10.
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.
9 have 1 digit (1-9)
90 have 2 digits (10-99)
1 has 3 digits (100)
Given numbers between 1 and 1000.
9 have 1 digit
90 have 2 digits
900 have 3 digits
1 has 4 digits
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.
Your results are actually expected. If the random numbers are uniformly distributed in a range 1 to 10^n, then you would expect about 9/10 of the numbers to have n digits, and a further 9/100 to have n-1 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:
function random_powerlaw(mini, maxi) {
return Math.ceil(Math.exp(Math.random()*(Math.log(maxi)-Math.log(mini)))*mini)
}
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).
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:
function random() {
return 4; // Chosen by a fair dice throw. Guaranteed to be random.
}
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.
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".
I tried JS pseudorandom number generator on Chaos Game.
My Sierpiński triangle says its pretty random:
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.
Non-random numbers uniformly distributed from 1 to N have the same property. Note that (in some sense) it's a matter of precision. A uniform distribution on 0-99 (as integers) does have 90% of its numbers having two digits. A uniform distribution on 0-999999 has 905 of its numbers having five digits.
Any set of numbers (under some not too restrictive conditions) has a density. When someone want to discuss "random" numbers, the density of these numbers should be specified (as noted above.) A common density is the uniform density. There are others: the exponential density, the normal density, etc. One must choose which density is relevant before proposing a random number generator. Also, numbers coming from one density can often be easily transformed to another density by carious means.