There are a few algorithms I think are simple enough to memorise yet seem universally useful enough to be bound to be good to know by heart at some point or other. LCG is one of them!<p>Something else that might be useful to know are methods to transform the uniform output of LCG into various other types of distribution shapes:<p>When U is uniform between 0 and 1 exclusive,<p>One can get an Exp(lambda) distributed variable with -log(U)/lambda<p>One can get a heavy-tailed Pareto(m,a) distributed variable with m/(1-u)^(1/a)<p>I'm still missing something easily memorable for bell-shaped distributions. The normal distribution would be nice because it's so easy to transform N(0,1) into a distribution with arbitrary parameters, but there's no simple way to compute the standard normal.
Great article, I love "because why not articles".<p>Checkout Perlin Noise, for when you need "smooth" and "natural" looking random numbers (making terrain, skies, waves, etc)<p><a href="https://www.youtube.com/watch?v=8ZEMLCnn8v0" rel="nofollow">https://www.youtube.com/watch?v=8ZEMLCnn8v0</a>
Deterministic pseudorandomness is really useful for seeding dummy data, data that you’d like to be fairly random (though it doesn’t need to be high-quality randomness, so LCG is fine) but consistent across runs/page loads.
Good stack overflow answer about js implementation of pseudorandom number generator: <a href="https://stackoverflow.com/a/47593316/1248177" rel="nofollow">https://stackoverflow.com/a/47593316/1248177</a>
I just watched a really good video explaination of this the other day: <a href="https://www.youtube.com/watch?v=4sYawx70iP4" rel="nofollow">https://www.youtube.com/watch?v=4sYawx70iP4</a>
The real value is the reference to the API calls which inherently represent less predictable seed state. If you can't call out, then these are acheing to be used alongside some kind of introspection into the runtime.
<i>“Each Math.random function created for distinct realms must produce a distinct sequence of values from successive calls.”</i><p>Nitpick: it would surprise me if any implementation implemented this requirement to the letter.<p>I think neither of the claims (FTA) “PRNGs are deterministic” and “A PRNG eventually repeats its sequence” are strictly required (for the first you can’t seed Javascript’s Math.Random, so there is no need to be able to regenerate a sequence; for the second, one could generate good pseudo random sequences that never repeat), but the implementations I’m aware of all have those properties, and use fixed-size state.<p>Given that, the number of PRNGs whose period is at most P is finite. So, one could exhaust that set by creating realms and random number sequences in each of them in a loop (a looooong loop)<p>The only ways to avoid generating a copy would be to gradually move to generators with more state or to crash.