A random seed initialises a reproducible pseudo-random stream. See why generator choice, call order, saved state and stream design matter in quant simulations.
Random seed
A random seed is an input used to initialise a pseudo-random number generator. It selects a reproducible starting state for a deterministic sequence. In a pricing or risk simulation, recording the seed helps a colleague replay the shocks behind a reported result, investigate a discrepancy and check a code change against the same scenarios.
The word random describes the intended statistical behaviour of the generated numbers. Once the generator and its starting state are fixed, its subsequent outputs are determined.
A sequence small enough to replay by hand
Consider this deliberately tiny teaching generator:
xn+1=(5xn+1)mod16.
The operation “mod 16” keeps the remainder after division by 16. Here the seed is the initial integer state x0, and we display each updated state directly. With seed x0=1, the first update gives 6, and the next gives 31mod16=15.
A tiny exact generator produces 6, 15, 12, 13 from seed 1 and repeats those outputs on restart. Seed 2 gives 11, 8, 9, 14. Discarding one output from seed 1 shifts the used sequence to 15, 12, 13, 2.
Original deterministic illustration using the stated recurrence. Values are integer states, not market observations or draws from a production generator.
The last row explains a common reproducibility failure: an extra draw inserted before the pricing calculation changes which values the calculation receives, even though the seed is unchanged. Distribution samplers can also consume different numbers of underlying draws, so replacing a sampling method can change later outputs.
This generator has only 16 states and cycles through all of them before returning to its start. It is useful for arithmetic, unsuitable for financial simulation. Its seed-1 stream reaches state 2 after five updates, so starting at seed 2 simply enters the same cycle at another position. Different seeds alone do not establish independence.
What to retain beside the seed
Modern generators often expand a simple integer seed into a much larger internal state. The seed and the current state are therefore different records: the seed helps restart a run; a saved state helps resume it partway through. A checkpoint must also preserve any state held by the surrounding sampler and calculation.
For a result that another person can replay, retain:
the generator and distribution-sampling algorithms;
the seed, or a documented saved state for a checkpoint;
the sequence of sampling calls and their arguments, including array sizes;
the software versions, build and relevant execution environment;
the model configuration, code revision and data snapshot.
These details matter even within one library. NumPy's compatibility policy ties replay to the same generator, seed, calls and arguments under strict environment conditions. It does not promise that every distribution sampler remains identical across versions or that separate scalar calls always match one array call.
The Reproducible Environments lesson develops the broader run record: code, dependencies, data and configuration belong beside the seed. Its full content requires membership; the link opens a public preview.
Replaying a run does not remove its sampling error
A fixed seed makes one Monte Carlo simulation repeatable. It does not make its realised estimate equal the target or validate the model.
For example, under the ideal model of 1,000 independent standard-normal draws, the sample mean targets zero and has standard error
SE(Zˉ)=10001≈0.03162.
Changing the seed generally changes the realised mean. Holding the model and sample size fixed leaves the target and theoretical standard-error scale unchanged. Selecting a seed because it produces an attractive estimate conceals the simulation's uncertainty.
Create a generator once and advance it as paths are generated. Restarting the same generator with the same seed inside every path can repeat the entire shock sequence; with identical model inputs, it repeats the payoff too. Treating those copies as independent paths gives an invalid uncertainty calculation.
For parallel jobs, use a generator's documented stream-splitting or spawning scheme and retain the assignment of streams to tasks. NumPy's parallel-generation guidance describes spawning streams designed to behave independently with very high probability. Merely giving workers different integer seeds is not a general proof of independence. Deliberately sharing aligned shocks for a common-random-numbers comparison is another valid design, provided the resulting dependence is handled explicitly.
