Skip to content(if available)orjump to list(if available)

A brief history of random numbers

A brief history of random numbers

31 comments

·October 28, 2025

camel-cdr

A history about random number generation isn't complete without mentioning George Marsaglias work.

He is responsible for multiply-with-carry, xorshift (the original version), KISS (a high quality generator predating the mersene twister) , the Ziggurat algorithm, diehard

Fun fact, one of the earliest methods for generating random mumbers, the middle square method, actually still passes all moderm statistical randomness test suites, if you hook up a weyl sequence to it: https://arxiv.org/abs/1704.00358

This, the middle square weyl sequence PRNG is my favoeite PRNG, because it's simple enough to implement from memory:

    uint64_t x, weyl;
    uint32_t msws(void) {
        x = x * x + (weyl += CONSTANT);
        return x = (x >> 32) | (x << 32);
    }
You just take a number, square it, advace and add the weyl sequence to it amd finally swap the lower and upper bits, using the trucated result as the output.

The CONSTANT is pretty much arbitrary, it just needs to be odd and not too regular. A good rule of thumb is to have no repeating or zero nibbles in each group of 4 bytes, e.g. 0xB5AD4ECEDA1CE2A9.

avadodin

That paper doesn't mention how many rounds it passed on the statistical tests, just that they tested 25000 seeds. They also don't definitely state a period but 2^64 with 192 or 384 bits of state is not that impressive. Furthermore, your version here uses only 128 bits so it is not clear to me that it is equivalent to the ones presented in the paper.

LPisGood

The Ziggurat algorithm is very important and widely used. There are some side channel vulnerabilities in differential privacy applications based on the details of this algorithm.

NoSalt

I dunno ... his saucy language made this very difficult to read.

ot

> Since nobody had figured out any downsides to PCG's yet, everyone shrugged and said "might as well just go with that then", and that is where, as of 2019, the art currently stands. The problem is solved, and life is good.

I wonder who "everyone" was, I'm not aware of many high-profile projects adopting PCG as a default. As of 2025, several high-profile runtimes (including all the major browsers) use xorshift variants [1]

Is there a list of users of PCG?

[1] See Adoption section in https://prng.di.unimi.it/

vlovich123

It kind of doesn’t matter if there are users - there are people still stupidly using Mersenne Twister. The point is that PCG is better than xorshift and related in that family. That other high profile applications haven’t switched is besides the point that PCG is objectively better:

> O'Neill proposes testing PRNGs by applying statistical tests to their reduced-size variants and determining the minimum number of internal state bits required to pass.[7] TestU01's BigCrush examines enough data to detect a period of 235, so even an ideal generator requires 36 bits of state to pass it. Some very poor generators can pass if given a large enough state;[8] passing despite a small state is a measure of an algorithm's quality, and shows how large a safety margin exists between that lower limit and the state size used in practical applications. PCG-RXS-M-XS (with 32-bit output) passes BigCrush with 36 bits of state (the minimum possible), PCG-XSH-RR (pcg32() above) requires 39, and PCG-XSH-RS (pcg32_fast() above) requires 49 bits of state. For comparison, xorshift*, one of the best of the alternatives, requires 40 bits of state,[5]: 19 and Mersenne twister fails despite 19937 bits of state.[9]

adgjlsfhk1

IMO there's plenty of reason to use Xoshiro over PCG. the quality differences between the best xoshiro and pcg differences are minimal (especially because most languages use a 256 bit state since it makes it easier to split/jump without worrying about duplicate streams), and Xoshiro generators tend to be easier to SIMD for when you need lots of random numbers.

WarrenWeckesser

The default bit generator in NumPy is PCG-64 [1].

[1] https://numpy.org/doc/stable/reference/random/bit_generators...

aj_hackman

Much like my beloved comb sort, I use xorshift because the implementation is small and it's Good Enough. God's Own 100 SLOC PRNG would have to be near-perfect and take three clock cycles to contemplate switching.

camel-cdr

> nobody had figured out any downsides to PCG's yet

BTW, people have broken PCG already: https://hal.science/hal-02700791/file/main.pdf

It takes up to 20000 CPU hours to break the seed from 512 output bits with an unknown state, increment and multiplier. (the multiplier is usually fixed constant)

tptacek

What does it mean to "break" PCG? It's not a secure random number generator.

camel-cdr

Seed recovery. It's not meant to be cryptographically secure, but previously nobody had reversed it.

Showing that reversal takes that many CPU hours shows how good the PRNG quality is.

olivia-banks

I love how this is written. A lot of things nowadays on this site, if only vaguely, make me think it was written in part by an LLM, but this didn’t fall into that category. Great read, bravo!

dswalter

Refreshing when technical writing has a sense of style.

Read it and gain a gnawing sense of unease at how "good" things might really be at present!

derbOac

Is there a good text on random number generation that someone on HN can recommend? I've read about various generators, pseudorandom and truly random, but those have always been scattered across various places, and I'm wondering if there's a good solid unified text on all of them, in terms of families of them and their underlying ideas, and their advantages and disadvantages.

Cold_Miserable

Xorshift, LCM and hardware rdrand work just fine. PCG and Weyl are overkill.

camel-cdr

sure, a += b is overkill

buildbot

I did not realize xorshift no longer as favored! Permuted Congruential Generators seems very cool. https://en.wikipedia.org/wiki/Permuted_congruential_generato...

lucasfcosta

This is what I come to HN for.

zkmon

Randomness is far more profound than it appears to be. Probably it doesn't even belong to the real (materialized) world.

buildbot

How so? I also find randomness profound but not sure what you mean but not belonging in the materialized world. Particle decay/Radiation is a pretty random process I believe?

card_zero

Possibly connecting random events to time, which is not material.

IAmBroom

The transformation of a particle into two more basic particles is absolutely material.

IAmBroom

Noether's Theorem states that it is fundamental to our real world - or else the apparent, fundamental symmetries of our physics are wrong.

websku

random numbers are not exactly random.

nachox999

natural random numbers are not (exactly) random or artifical generated random numbers are not (exactly) random?