Seeds and Reproducible Randomness

What a seed is

A pseudo-random generator holds an internal state and updates it each time you ask for a number. The seed is the value that sets that state at the start. Give the generator the same seed and the same sequence of calls, and it produces exactly the same numbers in the same order.

That can sound like a defect for something meant to be random, but it is a feature. Repeatability lets you debug, compare and share experiments that would otherwise produce a different answer on every run.

Seeding in practice

In Python’s standard library:

import random

random.seed(42)
print([random.randint(1, 6) for _ in range(5)])

random.seed(42)
print([random.randint(1, 6) for _ in range(5)])

The two printed lists are identical. The number 42 has no special property; any integer works, and different seeds give different sequences.

NumPy offers a similar approach with its newer generators:

import numpy as np

rng = np.random.default_rng(42)
rolls = rng.integers(1, 7, size=10)

Note the upper bound is exclusive here, so integers(1, 7) gives 1 to 6. A given seed gives the same output on the same library version, but different libraries produce different numbers from the same seed, so a seed is meaningful only together with the tool that used it.

In spreadsheets, RANDBETWEEN cannot be seeded and recalculates constantly. If you need a repeatable set of random rolls, paste the values once and keep that copy, or generate them in a script.

Why fix a seed

• Debugging. If a simulation produces a strange result, rerunning with the same seed reproduces the problem so you can inspect it.
• Comparing versions. Suppose you change a rule in your code and want to know whether the estimate moved. With the same seed on both versions, shared randomness cancels out, so differences are more likely to come from the change than from noise. This works best when the two versions consume random numbers in the same order.
• Sharing results. Others can reproduce your numbers exactly, which is the basis of checking someone’s claim.
• Writing tests. Automated tests for code with random elements need predictable output to pass or fail reliably.

What a fixed seed does not do

A fixed seed makes a result repeatable, not correct. If your estimate from seed 42 is 34.5 percent and the truth is 34.1, that gap is still sampling error and is the same every time. Running only one seed can lead you to mistake a lucky or unlucky stream for a stable finding.

For a trustworthy answer, run several seeds, or one large run, and look at the spread. If the estimate is stable across seeds, the sample is probably big enough. If not, you need more trials, as discussed in the Monte Carlo method.

Choosing and recording seeds

• Record the seed with every saved result. A result without its seed, library version and trial count is hard to reproduce.
• Avoid seeding inside a loop with the same value, which repeats the same numbers again and again and makes trials identical instead of independent.
• Let the system pick a seed when you want fresh randomness, usually by not seeding at all, and then log the seed it used if the tool offers that.
• Do not use predictable seeds for anything security-related. Reproducibility and secrecy pull in opposite directions.

Order matters

With a fixed seed, every call to the generator moves it forward. Add an extra random call early in your program, such as a debug shuffle, and every later number shifts. The program still works, but results no longer match earlier runs. Giving each part of a program its own generator, each with its own seed, reduces this problem. It also helps when running simulations in parallel, where sharing one generator across workers can cause duplicated or tangled streams.

Seeds in video games

Games use the same idea, sometimes visibly. Procedural worlds are often generated from a seed, which is why players can share a short code and get the same map. In some titles, the generator state is saved with the game, which is why save scumming works as it does: reloading restores the state and, if you repeat the same actions, can reproduce the same outcome. Speedrunners study how a starting seed is chosen and how it advances to manipulate results on purpose.

When a game reseeds from the clock on load, repeating an action gives different results. When it keeps the saved state, results can repeat. These are design choices, and a given game may do either.

A short checklist

1. Seed once at the start of a run.
2. Save the seed with the results.
3. Use several seeds before trusting an estimate.
4. Treat a seed as tied to a specific library and version.
5. Remove or randomize the seed again when you want genuinely varied behavior.

Used this way, seeds give the best of both worlds: the variety of random trials during analysis and the repeatability needed to check your own work.