There's Math.random(), and then there's Math.random() (2015)

In V8 engine, Math.random is implemented using xorshift128, which is a completely linear PRNG with 128 bits of state. Since you can recover 1 bit from each output, 128 outputs should be enoguh for you to setup a GF(2) linear system and solve for the state. Once you have the state, all you need is to simulate how V8 output future random values from state.

There are a series of challenges called "fastrology" from PlaidCTF 2023, which is about predicting Math.random() given some partial output (e.g. Math.floor(Math.random() * k)) with several variants. You can try to find writeups for that challenges, those solvers should be easy to adapt to predicting Math.random()>0.5 .

I've been studying this myself just a few days ago!

tl;dr For a "Math.random() > 0.5" function, you need ~128 successive outputs, each of which leaks exactly 1 bit of the state at that particular iteration, and then you "just" solve a system of linear equations over gf(2) to recover the full state for any given iteration.

You can use z3 to solve it automagically, or you can write your own gaussian elimination solver (which works out much faster than z3 in practice).

Math isn't exactly my strong suit, so it took me quite a bit of bashing my head against the wall to make sense of things and turn it into code, so I've been planning on writing a blog post that explains this all in-depth (or at least, as much depth as I understand it).

For Chrome, there's an added catch in that it generates random numbers in batches, and returns those batches in reverse-order, so you'd need to do a small brute-force to identify where the batch boundaries are in your output sequence.

For Firefox and Safari, there's an added catch in that they add together the two halves of the state before returning it. This can also be worked around with a small brute force.

That's not a nitpick at all — it has huge ramifications for how `Math.random()` needs to be interpreted. Many folks want it (and transformations of it!) to behave as though it were a true random variable sampled from a theoretically ideal [0, 1) uniform distribution.

But it's not, and will never be. It can only ever return values that have been rounded down to some floating point number. Even if you realize this, you still might expect it to be able to return _any_ floating point number x∈[0, 1) with `eps(x)` probability. But that's not typically the case, either. Typical implementations round down to the previous multiple of `eps(1.0)` or `eps(0.5)`.

You are correct, however picking floats uniformly like that is much more difficult, as some values should be thousands of orders of magnitude more likely to be picked than others. It's much easier to implement a generator that randomizes the mantissa and calls it a return.

Not java but a company I worked for had a perl application where old sales records were encrypted then put on dvd's for long term cold storage. I was a lowly tape monkey at the time so the actual details of the application were far above my pay grade. but long nights between shuffling tapes and swapping dvd I would try and figure out how the system worked. One thing I found out is that they were generating the encryption keys by combining a couple of values(something like secret + date I think) then hashing. They would then regenerate the key if the data ever needed to be retrieved. On it's own this is... fine I guess. cold records in a secure(ish) facility. The worrisome part was that they were using perl's rand(seed) as a hash function. Young me was like "well I don't know much about perl but I don't think there is any documentation guarantee about how exactly the rand(seed) function works." a few quick tests later and I found out that yes rand(seed) will return different values from different operating systems. and sometime even changing the version of perl was enough. They ended up having to make sure they went back to the same system the key was generated on then regenerate and store all keys used.

The lesson I learned, don't use random() when you want hash(). random is for non-deterministic output, hash is for deterministic output. random(seed) is an artifact of implementation and should never be used for deterministic output.

The real wtf was that this was perl on win98, probably due to when it was implemented, they wanted dvd burning capability and someone sort of knew perl.

Why is it unreasonable that given the same seed the same sequence will be generated? It's useful for generative art and video games at least. Sure it shouldn't be used for security...

I think this is no longer true:

https://www.baeldung.com/java-17-random-number-generators

https://openjdk.org/jeps/356

When they changed the iteration order of HashMap keys (1.7 I think?), tons of code broke, although fortunately mostly tests. It was easy to depend on it by doing something like creating a gold file test with expected results.

They don't want code to break like that, which means they need to preserve this sort of thing.

Isn't it normal to set a fixed seed in testing and then expect deterministic results so you can write simpler assertions?

Maybe its Minecraft?

The random floating-point numbers are not general-purpose, they are needed in applications whose input parameters are floating-point numbers.

For instance they are needed for testing the implementation of various functions of FP numbers, or for the so-called Monte-Carlo methods used for numerical integration, especially in multiple dimensions or for the solution of certain systems of equations with partial derivatives, or for the simulation of how some industrial product, e.g. an electronic integrated circuit, behaves when its components have random values of their characteristic parameters, within their accepted tolerances, as it always happens in any industrial production process, or the random numbers may be used in an optimization problem, to search through the possible solution space.

For random floating-point numbers it is frequent to need various other probability density distributions than uniform.

In most cases the best way to generate pseudo-random FP numbers is to derive them from uniform pseudo-random integers, using an appropriate method that will ensure the desired probability density distribution.

The uniform distribution of real numbers is easy to convert to other distributions, so if you want a language to have only one randomness function, it's a reasonable choice.

This is in javascript. All of the numbers are in floating point. (or were, initially)

Many of the algorithms for generating random numbers from different distributions want to start with uniform floats in [0,1) or (0,1]

In my field (music, video, games) random floating point numbers are ubiquitous.