Random Numbers: True vs Pseudo, Uses & Generation

Scenario

Range

Count

Repeats

硬币正反 / Coin flip

1 ~ 2

—

骰子 / Dice

1 ~ 6

1~6

yes

Double Color Ball (red)

1 ~ 33

Super Lotto (front)

1 ~ 35

Raffle / draw

name list

UUID v4

—

1~100

practically never

Random Numbers: True vs Pseudo, Uses & Generation

Updated 2026.08.01~3 min read

Computers generate pseudo-random numbers from seeds — deterministic but statistically random. True randomness needs physical entropy (atmospheric noise, hardware events). For games pseudo is fine; for cryptography only CSPRNG counts. Includes ranges, seeds, and fairness testing.

Key Takeaways

Pseudo-random (PRNG): algorithm + seed — same seed, same sequence; fast and fine for games/simulations

True random (TRNG): physical entropy sources — required for keys and draws with real stakes

CSPRNG: cryptographically secure PRNG (cannot be reverse-engineered from outputs)

Range math: random in [a,b] = a + rand() × (b−a+1) for integers — off-by-one is the classic bug

Core answer: A fair random number between 1 and N gives every value probability 1/N. Computers don't produce true randomness — they use pseudo-random number generators (PRNGs) seeded by entropy; for games that's fine, for cryptography you need CSPRNGs (like crypto.getRandomValues). Rolling two dice is NOT uniform: 7 appears 6/36 of the time, 2 and 12 only 1/36.

Uniform vs not: the dice table

Sum of 2d6	Ways	Probability
2 / 12	1	2.8%
3 / 11	2	5.6%
4 / 10	3	8.3%
5 / 9	4	11.1%
6 / 8	5	13.9%
7	6	16.7%

Sums of independent uniforms converge to a bell curve (Central Limit Theorem) — that is why board games balance around 7.

True random vs pseudo-random

PRNG (Math.random, rand()): deterministic sequence from a seed; fast; fine for shuffles, games, simulations. Never for keys or tokens.
CSPRNG (crypto.getRandomValues, /dev/urandom): seeded from OS entropy (timings, hardware noise); unpredictable even with full state knowledge of a PRNG.
Physical: dice, coin flips, atmospheric noise, quantum shot noise — true randomness, but slow and bias-prone in practice (a slightly worn die is measurably unfair over 10,000 rolls).

Worked examples

Example 1 — Shuffle fairness. The Fisher–Yates shuffle picks a uniform swap partner for each position in one pass; naive "sort by random key" or repeated swap-anywhere methods measurably bias orderings.

Example 2 — Sampling without replacement. Drawing 3 winners from 100 entries: P(any specific person picked) = 3/100, but P(all 3 specific) = 1/C(100,3) = 1/161,700.

Example 3 — The birthday paradox. Only 23 people make P(shared birthday) > 50%; at 60 people it is 99.4%. Intuition fails because pairs grow quadratically: C(23,2) = 253 pairs.

Common mistakes and myths

"Due" numbers — a fair die that missed 6 for 20 rolls is still 1/6 next roll; no memory exists (gambler's fallacy).
Modulo bias — rand() % 10 is slightly unfair when the generator's range is not a multiple of 10; use rejection sampling for correctness.
Using Math.random for security tokens — PRNG state can be reconstructed from outputs; session IDs need CSPRNG.
Confusing unlikely with rigged — a 1-in-a-million event happens ~8,000 times a day worldwide at population scale.
Testing randomness by eye — humans see patterns in noise (a fair coin yields streaks of 5+ regularly); use chi-square tests, not vibes.

Frequently Asked Questions

What is the difference between true and pseudo random?

Pseudo-random numbers come from deterministic algorithms: given the same seed, the sequence repeats exactly. They pass statistical randomness tests but are predictable if the seed leaks. True random numbers harvest physical entropy — atmospheric noise, radioactive decay, hardware jitter — and are non-reproducible. Games and simulations use PRNG; encryption keys and prize draws demand TRNG/CSPRNG.

How does a PRNG actually work?

A state transforms via a recurrence (e.g., linear congruential: next = (a×state + c) mod m), emitting bits each step. Modern algorithms (Mersenne Twister, xorshift, PCG) have periods like 2¹⁹⁹³⁷−1 — effectively never repeating in practice. The seed initializes the state, which is why the same seed replays the same "random" world in games like Minecraft.

What is a random seed?

The starting value of the generator's state. Seed 42 today and seed 42 tomorrow yield identical sequences — a feature for reproducible experiments, level generation and debugging; a disaster if used for passwords (attackers enumerate seeds). Systems auto-seed from OS entropy (timings, device noise); manual seeds belong in testing, never in security.

When do I need cryptographically secure randomness?

Whenever prediction costs money or safety: encryption keys, session tokens, password salts, lottery/draw winners, gambling shuffles. Language-default rand() (Math.random, C rand) is NOT secure — outputs leak internal state after enough samples. Use the CSPRNG: crypto.getRandomValues, secrets module, /dev/urandom. "Seems random" is not "unpredictable."

How do I test if random numbers are fair?

Quick checks: frequency test (1,000,000 dice rolls → each face ≈ 166,667 ± ~1,300), runs test (streaks should appear at predicted rates — no long streaks is itself suspicious), and chi-square for distribution shape. Real randomness looks clumpier than humans expect: 6 coin-flip heads in a row happens every ~64 flips on average. "Too smooth" signals tampering.

What are common random-number bugs?

(1) Off-by-one ranges — randInt(1,10) that can return 0 or never 10; (2) modulo bias — rand() % 10 slightly favors low digits when the range is not a divisor; (3) reseeding every call (seeding with the same millisecond → identical "randoms"); (4) using PRNG for security tokens; (5) assuming Math.random() is uniform across all doubles — it has only 53 bits of precision.