Random Seeds and Determinism

A lot of quantitative research code relies on randomness somewhere: a Monte Carlo simulation drawing thousands of random paths, a cross-validation routine randomly splitting data into folds, a machine learning model randomly initializing its weights before training. "Random" in a computer almost always means pseudo-random — generated by a deterministic algorithm that produces a long sequence of numbers that looks statistically random, starting from a fixed starting value called a seed. Given the same seed, the same code produces the exact same sequence of "random" numbers every single time. Given a different seed, or no seed specified at all (which usually means the seed is picked from something like the system clock), the same code produces a different sequence — and potentially a meaningfully different result — on every run.

Why this matters more than it sounds like it should

If a researcher runs a Monte Carlo VaR calculation and gets a number, then a colleague runs the exact same code the next day and gets a slightly different number, the natural question is whether something is actually wrong. If the seed wasn't fixed, the answer is simply "no, that's just random variation from a different random draw" — but without knowing to check the seed, that innocent explanation can waste hours of confused debugging chasing a phantom discrepancy. The same problem shows up in model training: a machine learning model's reported performance can shift noticeably between runs purely because of random weight initialization or a random train/test split, making it hard to tell whether a code change genuinely improved the model or the improvement is just noise from a different seed.

A concrete case

A researcher backtests a strategy that uses random subsampling to estimate the stability of a signal's performance across different data slices. The first run reports the signal is stable across 95% of subsamples; a re-run a week later, with the seed left unset, reports 91%. Neither number is wrong, but neither is directly comparable to the other, and if the researcher had reported the first number as "the" result without noting it depended on an unfixed seed, anyone trying to check the work would get a different answer and reasonably suspect a bug.

What this means in practice

Fixing and recording the random seed for any result that will be reported, compared, or relied upon is close to free — one line of code — and it converts "did this change because of my code or because of randomness" from a genuine mystery into a question that's trivially answered by checking whether the seed was the same. Note that even a fixed seed doesn't guarantee identical results across different hardware, library versions, or parallel execution — those introduce their own sources of nondeterminism that seed control alone doesn't solve.