rand(3erl)

📦

version 25.3.2.8 · 5 versions

🌸 NAME 🌸

rand — pseudo random number generation, but make it a whole moment.

Okay bestie, welcome to rand(3erl) from the Erlang Module Definition manual ✨ this is the module you call when you need numbers that are random-ish and you need them now. Like, it literally does what it says on the tin: pseudo random number generation. Let's get into it 💅

🎀 DESCRIPTION 🎀

So this module hands you a pseudo random number generator, and it's not just one algorithm — it's a whole little roster 🫶 The uniform distribution algorithms are built on the Xoroshiro and Xorshift algorithms by Sebastiano Vigna. The normal distribution algorithm uses the Ziggurat Method by Marsaglia and Tsang, layered right on top of the uniform distribution algorithm.

For most algorithms, there are also jump functions for generating non-overlapping sequences so you can do parallel computations. The jump functions do the equivalent of performing a large number of repeated calls for calculating new states — but they run in a time roughly equivalent to one regular iteration per generator bit. So like, same destination, way shorter flight ✈️

And heads up: at the end of this module documentation there are also some niche algorithms to be used without this module's normal plug-in framework API — useful for special purposes like short generation time when quality is not essential, for seeding other generators, and such. Little side quests, iykyk.

🌈 The algorithms, ranked by yours truly 🌈

`exsss`

Xorshift116**, 58 bits precision and period of 2^116-1.

Jump function: equivalent to 2^64 calls.

This is the Xorshift116 generator combined with the StarStar scrambler from the 2018 paper by David Blackman and Sebastiano Vigna: Scrambled Linear Pseudorandom Number Generators.

The generator does not need 58-bit rotates so it is faster than the Xoroshiro116 generator, and when combined with the StarStar scrambler it does not have any weak low bits like exrop (Xoroshiro116+).

Alas 😭 this combination is about 10% slower than exrop, but is despite that the default algorithm thanks to its statistical qualities. Slower but slay-ier, we love a queen with standards.

`exro928ss`

Xoroshiro928**, 58 bits precision and a period of 2^928-1.

Jump function: equivalent to 2^512 calls.

This is a 58 bit version of Xoroshiro1024**, from the 2018 paper by David Blackman and Sebastiano Vigna: Scrambled Linear Pseudorandom Number Generators — that on a 64 bit Erlang system executes only about 40% slower than the default exsss algorithm, but with much longer period and better statistical properties, but on the flip side a larger state.

Many thanks to Sebastiano Vigna for his help with the 58 bit adaption 🫶 icon behaviour honestly.

`exrop`

Xoroshiro116+, 58 bits precision and period of 2^116-1.

Jump function: equivalent to 2^64 calls.

`exs1024s`

Xorshift1024*, 64 bits precision and a period of 2^1024-1.

Jump function: equivalent to 2^512 calls.

`exsp`

Xorshift116+, 58 bits precision and period of 2^116-1.

Jump function: equivalent to 2^64 calls.

This is a corrected version of the previous default algorithm, that now has been superseded by Xoroshiro116+ (exrop). Since there is no native 58 bit rotate instruction this algorithm executes a little (say < 15%) faster than exrop. See the algorithms' homepage.

👑 The default situation 👑

The current default algorithm is exsss (Xorshift116**). If a specific algorithm is required, ensure to always use seed/1 to initialize the state. No cap, do the seeding.

Which algorithm that is the default may change between Erlang/OTP releases, and is selected to be one with high speed, small state and "good enough" statistical properties.

Undocumented (old) algorithms are deprecated but still implemented so old code relying on them will produce the same pseudo random sequences as before. Nostalgia, but make it backwards compatible 💀

⚠️ Note: why the old ones are deprecated ⚠️

There were a number of problems in the implementation of the now undocumented algorithms, which is why they are deprecated. The new algorithms are a bit slower but do not have these problems:

Uniform integer ranges had a skew in the probability distribution that was not noticable for small ranges but for large ranges less than the generator's precision the probability to produce a low number could be twice the probability for a high. Rude.
Uniform integer ranges larger than or equal to the generator's precision used a floating point fallback that only calculated with 52 bits which is smaller than the requested range and therefore were not all numbers in the requested range even possible to produce. Literally unreachable numbers 😭
Uniform floats had a non-uniform density so small values i.e less than 0.5 had got smaller intervals decreasing as the generated value approached 0.0 although still uniformly distributed for sufficiently large subranges. The new algorithms produces uniformly distributed floats on the form N * 2.0^(-53) hence equally spaced. Equally spaced is the vibe 🌸

🦋 State, implicit vs explicit 🦋

Every time a random number is requested, a state is used to calculate it and a new state is produced. The state can either be implicit or be an explicit argument and return value.

The functions with implicit state use the process dictionary variable rand_seed to remember the current state.

If a process calls uniform/0, uniform/1 or uniform_real/0 without setting a seed first, seed/1 is called automatically with the default algorithm and creates a non-constant seed. It's giving self-care, the module seeds itself 💅

The functions with explicit state never use the process dictionary. Not once. Zero notes.

✨ Examples (the good stuff) ✨

Simple use; creates and seeds the default algorithm with a non-constant seed if not already done:

R0 = rand:uniform(),
R1 = rand:uniform(),

Use a specified algorithm:

_ = rand:seed(exs928ss),
R2 = rand:uniform(),

Use a specified algorithm with a constant seed:

_ = rand:seed(exs928ss, {123, 123534, 345345}),
R3 = rand:uniform(),

Use the functional API with a non-constant seed:

S0 = rand:seed_s(exsss),
{R4, S1} = rand:uniform_s(S0),

Textbook basic form Box-Muller standard normal deviate:

R5 = rand:uniform_real(),
R6 = rand:uniform(),
SND0 = math:sqrt(-2 * math:log(R5)) * math:cos(math:pi() * R6)

Create a standard normal deviate:

{SND1, S2} = rand:normal_s(S1),

Create a normal deviate with mean -3 and variance 0.5:

{ND0, S3} = rand:normal_s(-3, 0.5, S2),

🔒 Note (important, bestie, read this one): The builtin random number generator algorithms are not cryptographically strong. If a cryptographically strong random number generator is needed, use something like crypto:rand_seed/0. Do not use these to generate your passwords, I'm begging 🙈

💀 Note (the low-bits situation): For all these generators except exro928ss and exsss the lowest bit(s) has got a slightly less random behaviour than all other bits. 1 bit for exrop (and exsp), and 3 bits for exs1024s. See for example the explanation in the Xoroshiro128+ generator source code: "Beside passing BigCrush, this generator passes the PractRand test suite up to (and included) 16TB, with the exception of binary rank tests, which fail due to the lowest bit being an LFSR; all other bits pass all tests. We suggest to use a sign test to extract a random Boolean value."

If this is a problem; to generate a boolean with these algorithms use something like this:

(rand:uniform(256) > 128) % -> boolean()

((rand:uniform(256) - 1) bsr 7) % -> 0 | 1

For a general range, with N = 1 for exrop, and N = 3 for exs1024s:

(((rand:uniform(Range bsl N) - 1) bsr N) + 1)

The floating point generating functions in this module waste the lowest bits when converting from an integer so they avoid this snag. Problem? Solved. Periodt 💅

💜 DATA TYPES 💜

`builtin_alg()`

builtin_alg() =
    exsss | exro928ss | exrop | exs1024s | exsp | exs64 |
    exsplus | exs1024 | dummy

`alg()`

alg() = builtin_alg() | atom()

`alg_handler()`

alg_handler() =
    #{type := alg(),
      bits => integer() >= 0,
      weak_low_bits => integer() >= 0,
      max => integer() >= 0,
      next :=
          fun((alg_state()) -> {integer() >= 0, alg_state()}),
      uniform => fun((state()) -> {float(), state()}),
      uniform_n =>
          fun((integer() >= 1, state()) -> {integer() >= 1, state()}),
      jump => fun((state()) -> state())}

`alg_state()`

alg_state() =
    exsplus_state() |
    exro928_state() |
    exrop_state() |
    exs1024_state() |
    exs64_state() |
    dummy_state() |
    term()

`state()`

state() = {alg_handler(), alg_state()}

Algorithm-dependent state. It's the little bundle of algorithm + state, matching set 🎀

`export_state()`

export_state() = {alg(), alg_state()}

Algorithm-dependent state that can be printed or saved to file. Screenshot it, print it, frame it, whatever 🖼️

`seed()`

seed() =
    [integer()] | integer() | {integer(), integer(), integer()}

A seed value for the generator. Three flavours, pick your fighter:

A list of integers sets the generator's internal state directly, after algorithm-dependent checks of the value and masking to the proper word size. The number of integers must be equal to the number of state words in the generator.
An integer is used as the initial state for a SplitMix64 generator. The output values of that is then used for setting the generator's internal state after masking to the proper word size and if needed avoiding zero values.
A traditional 3-tuple of integers seed is passed through algorithm-dependent hashing functions to create the generator's initial state.