Random Tools — flip a coin, roll dice, spin a wheel

How to use Random

Start by asking what the randomness is for, because the answer decides which kind you need. Picking a winner, shuffling a playlist and generating a password are three different problems that look identical from outside.

Fair choice between options — any decent generator works. Shuffling a list — needs a proper shuffle algorithm, not repeated sorting by random values. Anything secret — passwords, tokens, keys — needs a cryptographic generator specifically.

Reproducible results for testing — needs a seed you record, which makes it deliberately not random.

Pseudorandom is not random

Most computer randomness is pseudorandom: a deterministic sequence that looks unpredictable but is fully determined by a starting value called the seed. Give the same seed twice and you get the same sequence twice. This is a feature for simulations and tests, where you want to reproduce a run exactly, and a serious problem for anything that must be unguessable.

Cryptographic generators are built to resist prediction even by someone who has seen a lot of the output. The distinction is not about statistical quality — a good pseudorandom generator passes statistical tests fine. It is about whether an adversary can work backwards.

A random number generator that is easy to reason about is usually easy to predict. Those are the same property viewed from opposite sides.

Where intuition fails

People are consistently bad at recognising randomness, in a specific and predictable direction: real random sequences contain more clustering and repetition than people expect, and sequences people invent contain less. Ask someone to write a "random" string of coin flips and they will alternate too often and avoid long runs.

This has practical consequences. Genuinely shuffled music sounds broken to listeners, because the same artist appears twice in a row and that feels like a bug. Some music services deliberately un-randomise their shuffle to spread artists out — making it less random so that it feels more so.

The related error is expecting randomness to self-correct. A fair coin that has landed heads five times has exactly even odds on the sixth flip. Nothing is owed, nothing balances out, and the sequence has no memory of what it did before.

Getting a shuffle right

Shuffling is the operation people most often implement badly, because the wrong version looks right. Use a standard shuffle from your language's library if one exists. If implementing one, use the Fisher-Yates method: walk the list from the end, swapping each item with a randomly chosen earlier position.

Do not sort the list by a random key — it produces uneven distributions and can break the sort itself. Test with a small list and many runs: every arrangement should appear at roughly equal frequency.

When you want less randomness

Plenty of situations described as "random" actually want something else. A random ordering that must not repeat needs sampling without replacement. A random assignment that must be reproducible needs a recorded seed. A random selection that must be verifiable by someone else needs a published method rather than a private roll.

The last case matters for anything with stakes — prize draws, audits, sampling for inspection. If the outcome only has to be random, a generator is enough. If it has to be demonstrably random to a sceptical observer, the process needs to be visible and checkable, and a black box that says "trust me" will not do it.