Skip to content
PlagiatScanner.de
Research data · DAT-12

How to document a random seed in research

A random seed fixes the reproducible starting state of a pseudo-random process. Put it in the executable analysis, identify the generator, software and package versions, then re-run from a clean session. The same number does not guarantee the same result across every system: algorithms, parallel execution, hardware and the order of random calls can all alter the sequence.

Mini-experiment and checklistReviewed 4 September 2026

What a seed controls—and what it does not

Most analytical software does not obtain fresh physical randomness for every ordinary task. It generates a deterministic sequence from an internal starting state. The seed establishes that state. When the same generator receives the same calls under the same conditions, it returns the same sequence. This matters for sampling, train-test splits, simulation, bootstrapping, imputation and randomly initialised models.

The seed is not a methodological justification. The familiar value 42 is no more scientific than 7319. What matters is that the choice is made independently of the desired result and preserved. If a method is sensitive to initialisation, assess it over several pre-specified, independent seeds rather than selecting the run that looks most favourable.

Why an identical seed can still produce a different answer

Languages and libraries may use different pseudo-random algorithms, and defaults can change between releases. Call order matters too: one extra random draw early in a script shifts all later values. Parallel workers may receive substreams differently. Some GPU operations are not fully deterministic, while small floating-point changes can grow through an iterative model.

The record must therefore connect the number to its environment. Name the interpreter, relevant packages and consequential hardware. Libraries that create their own random objects may need a separate seed rather than a global setting. Use the official documentation to identify which components accept an explicit generator or random state.

Place the instruction at the true start of randomness

Set the state after loading the environment but before the first stochastic operation. Keep the command in the file that actually runs, not merely in the dissertation prose. A comment should state its purpose, such as “seed for the training and test partition”. Notebook workflows deserve extra care because cells can be run out of order; restart the kernel and execute the complete notebook from top to bottom.

Where several stages are logically independent, controlled random streams or explicitly documented stage-specific seeds can prevent accidental coupling. Avoid inventing a new value during debugging without recording the change. A central configuration file can help, provided it is versioned with the analysis and read by the released code.

Authority asset: five-step seed experiment

  1. Create a small script that sets a seed, draws ten values and writes them to a file.
  2. Close the process completely, run the same script again and compare the file or checksum.
  3. Add one random draw before the recorded sample; observe how the later sequence moves.
  4. Reset the same seed immediately before the recorded sample and check whether the initial output returns.
  5. In a separate environment, change only the generator or library version and record whether the sequence survives.

The exercise isolates four variables: seed value, generator, call order and software environment. Use the same diagnostic logic when documenting the real analysis.

Audit checklist for a controlled random state

  • The value appears in executable code rather than only in the methods section.
  • The library, generator and stochastic function are identified.
  • Software and package versions, and relevant hardware, are recorded.
  • The first random operation and the reason for randomness are explained.
  • Parallelism, GPU use and deterministic options are stated.
  • A clean-session run has been completed and meaningful outputs compared.
  • Multiple-seed sensitivity has been assessed where the method warrants it.

Preserve the audit with the code and outputs. A screenshot of a console command can support the record, but searchable text and an executable file are easier to inspect and less likely to omit context.

Report enough detail for an independent re-run

A compact statement should connect the procedure to its location: “The split used generator … with seed … in software … version …; executable implementation is in file … at …”. For a stochastic model, add the number of independent runs and explain how their results were summarised. This preserves one run while keeping uncertainty visible.

If a third-party tool offers no way to control the state, say so. Preserve its inputs, outputs, time and version and repeat the process to characterise observed variation. Do not promise exact reproducibility when the necessary control is unavailable. Link the record to your broader software environment documentation.

Random splits, selective reporting and research integrity

In machine learning, randomness may determine which cases become training or test observations. Trying many seeds and reporting only the strongest metric distorts the evaluation. Define the selection rule and target metric before inspecting outcomes. Retain unsuccessful runs in the analysis log. The random state is therefore not just technical metadata; it is part of the evidence for how a result was selected.

Official documentation

  1. Python documentation: random – generator state, seeding and reproducibility notes.
  2. R Manual: Random Number Generation – RNG types, state and version handling.
  3. NumPy: Random sampling – official guidance on generators and random objects.

Continue the workflow

Research data hubRecord the software environmentUnderstand the evidence trail