Why Record a Seed?
A simulation uses generated random outcomes to imitate a chance process. When an analyst changes code, checks a calculation, or shares results, it is useful to be able to run the same simulation again and obtain the same output. A seed helps make that possible: it sets the initial state of a pseudorandom number generator.
A seed is not a guarantee that every program will produce the same sequence. Reproduction also depends on the generator algorithm, software implementation, how random numbers are drawn and used, and the details of the simulation. A useful simulation record therefore documents both the seed and the setup around it.
What Reproducibility Requires
A pseudorandom generator is deterministic: once its starting state and algorithm are fixed, each next state and output are determined. In simplified notation, if the generator updates its state according to \(S_{k+1}=g(S_k)\) and produces an output \(U_k=h(S_k)\), then the same starting state produces the same first output. That output leads to the same next state, which produces the same second output, and so on. Repeating this argument shows that the sequence is the same for any fixed number of steps, provided the algorithm and operations are unchanged.
This is why a seed is useful, but also why recording only a seed is incomplete. Two programs might interpret a seed using different generator algorithms. A program update might change its default generator. Even with the same generator, a changed order of calls can assign different random values to different trials. Reproducibility means repeating the full procedure, not merely typing the same seed into an unspecified program.
A practical record should identify at least the following:
- Simulation model: what chance process is represented and what probabilities or other inputs are used.
- Trial definition: what counts as one trial, including how many random draws it uses and whether trials are treated as independent.
- Event definition: the precise condition counted as a success, including boundary conventions such as “less than” versus “less than or equal to.”
- Run size: the number of trials actually completed, not merely the number planned.
- Random-number setup: the seed, generator algorithm, and software or library version.
- Implementation: the code or a sufficiently precise description of the random-number mapping, draw order, and any stopping rule.
- Output: the number of successes and the reported estimate, with enough detail to check the calculation.
For a simulation that estimates a probability, if \(I_i=1\) when trial \(i\) meets the event definition and \(I_i=0\) otherwise, the simulated proportion is
The trial count \(n\), success count \(\sum I_i\), and event rule should all be available in the record. A reported proportion without these details can be difficult to reproduce or interpret.
Worked Examples
Worked Example: Repeating a Threshold Simulation
Suppose a fully specified hypothetical pseudorandom generator, initialized with seed 31415, produces these seven values for a demonstration run:
\(0.25,\ 0.3125,\ 0.625,\ 0.1875,\ 0,\ 0.0625,\ 0.375\).
The simulation defines event A as “the generated value is below 0.5.” The stated model treats each generator output as a draw intended to represent a uniform value between 0 and 1. For this demonstration, one trial uses one output, and the run has \(n=7\) trials.
The values below 0.5 are \(0.25,\ 0.3125,\ 0.1875,\ 0,\ 0.0625,\) and \(0.375\). The third value, \(0.625\), is not below 0.5, while the seventh value, \(0.375\), is. Thus there are six successes, and
The record should state the seed, generator and implementation, event A as \(U<0.5\), that each trial uses one output, and that seven trials were run. It should also report six successes and the resulting simulated proportion, approximately 0.8571. Another analyst can then check both the classification of the listed outputs and the arithmetic. The displayed values are hypothetical; they do not claim that a particular commercial program produces this sequence from that seed.
Worked Example: Recording a Two-Coin Simulation
Consider a hypothetical simulation of two fair coin tosses per trial. It generates two values intended to be independent uniform draws on \([0,1)\), using the rule “head if \(U<0.5\), tail otherwise.” The event of interest is at least one head in the two tosses. Suppose the run record contains the following ten pairs of generated values:
| Trial | First value | Second value | Simulated tosses | Event? |
|---|---|---|---|---|
| 1 | 0.12 | 0.74 | HT | Yes |
| 2 | 0.89 | 0.31 | TH | Yes |
| 3 | 0.55 | 0.67 | TT | No |
| 4 | 0.04 | 0.22 | HH | Yes |
| 5 | 0.78 | 0.93 | TT | No |
| 6 | 0.48 | 0.51 | HT | Yes |
| 7 | 0.33 | 0.16 | HH | Yes |
| 8 | 0.61 | 0.44 | TH | Yes |
| 9 | 0.27 | 0.82 | HT | Yes |
| 10 | 0.96 | 0.08 | TH | Yes |
There are eight “Yes” results among ten trials, so the simulated proportion is
To make this record reproducible, the analyst would also record the seed, generator, software version, and the code or instructions that generate two values per trial and map each value to a toss. The model assumptions for the intended simulation are that each value behaves as a uniform draw and the two draws within a trial, as well as draws across trials, are treated as independent. The table allows another analyst to verify the mapping and count; the setup details allow the analyst to attempt to regenerate the table.
Worked Example: Why the Event Rule Belongs in the Record
Suppose a recorded run has \(n=12\) generated values:
\(0.12,\ 0.50,\ 0.73,\ 0.08,\ 0.49,\ 0.51,\ 0.50,\ 0.91,\ 0.27,\ 0.62,\ 0.44,\ 0.88\).
One analyst defines success as \(U<0.5\). The successful values are \(0.12,\ 0.08,\ 0.49,\ 0.27,\) and \(0.44\), giving five successes. That analyst reports
Another analyst uses \(U\leq 0.5\). In addition to those five values, the two values equal to 0.50 count as successes, so there are seven. This analyst reports
Both calculations follow their stated event rules, but they do not describe the same event. Although exact equality to a threshold has probability zero for an ideal continuous uniform draw, a computer generator has finite precision and can produce a value equal to a threshold. The record must specify the inequality actually used. Here the two estimates differ by \(7/12-5/12=2/12=0.1667\), so leaving the boundary rule unstated makes the result ambiguous.
A Reproducible Simulation Record
A simulation record is a compact account of what was run, not simply a seed written beside a result. It should make the intended model and the computational steps clear enough that someone else can repeat the procedure and check its output. A useful record might include these fields:
| Record field | What to specify |
|---|---|
| Question and model | The chance process being represented and its input probabilities or parameters |
| Trial and event | What one trial does and the exact rule for counting a success |
| Run size | The number of completed trials and any stopping rule |
| Random-number details | Seed, generator algorithm, software or library version, and any stream or substream identifier |
| Implementation | Code or precise instructions, including draw order and mapping of generated values to outcomes |
| Result | Success count, any other reported output, and the calculation that produces the estimate |
If an analysis uses a software default for the generator, naming the software and version is still important: defaults can change. If the generator has a named algorithm, record that name rather than saying only “random numbers.” Preserve the code when possible. If the simulation uses several random streams, record how each stream is initialized and assigned. If it stops when a condition is met rather than after a fixed number of trials, state that rule and the number of trials actually reached.
A seed also does not make a simulation truly random or establish that its model is appropriate. It supports repeatability of a computation. Whether the modeled outcomes represent the chance process of interest is a separate question. Likewise, reproducing the same output is not the same as independently validating the program or the assumptions. Keeping the model and code in the record makes those questions easier to examine.
Common Mistakes and Why They Matter
- Recording only the seed. The mistaken reasoning is that the same seed must always give the same result. The correction is that the same seed reproduces a sequence only under a compatible generator, implementation, version, and order of random-number use.
- Leaving the event informal. “Count values near one-half” does not specify a testable condition. Write the precise rule, such as \(U<0.5\), and include boundary handling.
- Reporting the planned rather than completed trial count. If a run planned 10,000 trials but stopped after 8,400, a success proportion must use the completed count. The record should say what actually ran.
- Keeping only the final proportion. A proportion such as 0.42 does not reveal the denominator or success count. Record both; for example, 42 successes out of 100 trials gives \(42/100=0.42\).
- Assuming a repeated run is independent evidence. Reusing the same seed and setup intentionally repeats the same pseudorandom sequence. It is useful for checking reproducibility, but it is not a new independent simulation run.
These practices matter when results need to be checked, when code is revised, and when collaborators need to determine whether a difference arose from the model, event definition, random-number setup, or arithmetic. A clear record makes a computational result inspectable rather than merely repeatable.
Check Your Understanding
Try these questions without looking back.
- What does a seed determine in a pseudorandom number generator, and what additional details are needed to reproduce a run reliably?
- A report gives a seed and a simulated proportion but not the number of trials. What information needed to check the estimate is missing?
- Why should a simulation record specify whether success is defined by \(U<0.5\) or \(U\leq 0.5\)?
- A program is run twice with the same seed, but the second version makes an extra random-number call before beginning the trials. Why might the trial outcomes differ?
- What should be reported if a simulation was planned for 5,000 trials but stopped after 4,200?