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).
Related
Is there a way to get the functionality of c++'s std::nextafter in Elm? I'm happy to use an external javascript function if that's the only way.
For background, std::nextafter is a function taking a floating point number and returning the next representable floating point number by size.
As for X... nextafter library provides this functionality, and I doubt very much whether Elm would have anything built in... it's just not a frequently useful procedure.
As for Y, honestly, you're not going about this the right way. The reason that nextafter wasn't added until C++11 is that it's not widely useful. In particular, if you plan to use it to give some interface a number which is strictly greater than a given number, while remaining as close to it as possible, prepare for disappointment. Many such interfaces will do initial operations which can have the effect of abnegating that strict ordering. And if you plan to iterate over all the numbers in some range... keep in mind that there are about 4 billion billion of them between 0 and 1.
In JavaScript, is it possible to generate a random number from another number?
I'm trying to implement a predictable random number generator for one of my fractal terrain generators. I already know that it's possible to generate a random number using Math.random(), but I want to create a random number generator that produces exactly one output for every input. (For example, predictableRandomGenerator(1) would always produce the same result, which would not necessarily be the same as the input.)
So is it possible to generate a random number from another number, where the output is always the same for each input?
You can use a checksum generator such as MD5 or SHA-1 to generate a single pseudo-random output for every input. SHA-1 will generate a random number from each string that is entered as input, and each output will produce exactly one input. (It's likely that any other checksum generator would be suitable for thus purpose as well, since checksum generators produce exactly one output for each input that is entered).
Yes, it is possible. However you'll need to write your own pseudo-random number generator.
See, computers can't really generate random numbers. However you can use an algorithm which creates a sequence of numbers which appears to be random.
This algorithm is usually given a seed and each seed leads to a different sequence of random numbers generated by the algorithm.
The most common algorithm is the linear congruential pseudorandom number generator, as defined by D. H. Lehmer and described by Donald E. Knuth in The Art of Computer Programming, Volume 2: Seminumerical Algorithms, section 3.2.1.
For more details refer to the following thread: Predict the Seed of Javascript's Math.random
Sure, how about the identity function:
function getMappedRandom(random){ return random; }
I'm not sure why you want this transformation, but in terms of randomness it does not necessarily make it better.
I believe what you need is called one-way hash function. try hex_md5() or hex_sha1().
If you need a PRNG for a terrain generator, then I'm assuming you need a seeded random number generator that reproduces the sequence of pseudo-random numbers for a given seed; Such that each seed creates a separate, distinct terrain that can be reconstructed later by providing the same seed.
This might work for you:
http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html
http://davidbau.com/encode/seedrandom.js
I'm looking to build a browser multiplayer game using rollback netcode that runs a deterministic simulation on the clients. I prototyped the netcode in Flash already before I ran into the floating point roadblock.
Basically, from what I understand, integer math in Flash is done by casting ints to Numbers, doing the math, then casting back to int. It's faster apparently, but it means that there's no chance of deterministic math across different computer architectures.
Before I dump all my eggs into the JavaScript basket then, I'd like to ask a few questions.
Is there true integer arithmetic on all major browsers in JavaScript? Or do some browsers do the Flash thing and cast to floats/doubles to do the math before casting back to int?
Does something like BigDecimal or BigNum work for deterministic math across different computer architectures? I don't mind some performance loss as long as it's within reason. If not, is there some JavaScript fixed point library out there that solves my problem?
This is a long shot, but is there a HTML5 2D game engine that has deterministic math for stuff like x/y positions and collisions? The list of game engines is overwhelming to say the least. I'm uneasy about building a deterministic cross browser compatible engine from scratch, but that might be what I have to do.
NOTE: Edited from HTML5 to JS as per responses. Apologies for my lack of knowledge.
This is a Javascript issue - not an HTML5 one.
All Javascript math is done using IEEE754 floating point double values - there are no "ints".
Although IEEE754 requires (AFAIK) a specific answer for each operation for any given input, you should be aware that JS interpreters are potentially free to optimise expressions, loops, etc, such that the floating point operations don't actually execute in the order you expect.
Over the course of a program this may result in different answers being produced on different browsers.
I'm currently making my own BigInt class, by splitting numbers by 7 digits. (i.e. in base 10,000,000)
I implemented addition, subtraction, and multiplication, and now I'm implementing division and mod. I wrote a code that performs division by long division (estimating numbers by dividing most-significant digits), and it works.
However, it is too slow. When I test operations on a 108-digit number and a 67-digit number, it takes 1.9ms to calculate division, much slower than other operations(0.007~0.008ms to calculate addition/subtraction, 0.1ms to calculate multiplication).
Like Karatsuba and FFT algorithm for fast multiplication, what algorithm exists for calculating division? Wikipedia demonstrates some division algorithms (which calculates multiplicative inverse of divisor and multiplies it with dividend), but I think that doesn't help me much implementing division. I read 'Large integer methods' sections too but that doesn't help me too... :(
The standard reference for big-integer arithmetic is Donald Knuth's book Art of Computer Programming, Volume 2, Section 4.3. His division algorithm is basically the grade-school algorithm, with some small improvements.
By the way, most people that implement big-integer arithmetic use a power of two rather than a power of ten as the radix of their number system.
I'd suggest you have a look at the source code of the GMP library and port the functionality you need to JavaScript, or get an idea of how it's done.
If there is a good algorithm out there, this library will most likely have it; and it is distributed under the LGPL.
For a reasonably fast division algorithm, look at http://myweb.lmu.edu/dmsmith/MComp1996.pdf
It is still O(n^2) but efficient for moderate lengths. It is especially well suited when you are using bases that are smaller than the word size. Years ago, I implemented it in Python. The code is buried in http://home.comcast.net/~casevh/decint_041.tar.gz . Look for the functions smithdiv() and remainder_norm().
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.