Why Random-Number Settings Belong in the Analysis Record
MICE uses random draws during imputation. Those draws help determine such features as sampled model parameters and imputed values, so two runs of the same analysis can differ if they start from different random-number states. A seed gives a pseudorandom number generator (RNG) a reproducible starting point. Recording it is a practical part of making an imputation workflow auditable.
A seed is not a guarantee that the same results will be produced on every computer, by every software version, or under every execution arrangement. Exact repeatability requires more than knowing one integer: the data, preprocessing, code, RNG configuration, software environment, and sequence of random-number requests must also agree. Locking Software Environments for MICE addresses the environment record; this tutorial focuses on the random-number settings and on checking what a repeat run reproduces.
Set the Seed Before the Stochastic Work
In R, a common approach is to call set.seed() immediately before the stochastic part of the analysis. Some MICE functions also provide a seed argument. Choose one approach deliberately, document where the seed is applied, and avoid resetting it in unexplained locations. If preprocessing itself uses random operations, set and record the seed before those operations too.
A seed does not describe the entire RNG configuration. R provides RNGkind() to report the kinds of generators used, including the uniform generator and, where relevant, the normal generator and sampling method. Record these settings along with the R version, MICE package version, seed value, and a description or version-control identifier for the analysis code. Record enough information to identify the data and preprocessing as well; an identical seed cannot compensate for changed input.
A practical run record should make the execution reproducible by another analyst, rather than merely preserve a seed number. It should identify the seed-setting call or function argument, the RNG kinds, the number of imputations, the number of iterations, the methods and predictor setup, and the software environment. Do not publish sensitive data in the record; use an appropriate data identifier or secure location.
Use the intended data, preprocessing, MICE settings, and analysis code. Confirm that these are the versions you plan to document.
Record the seed and the reported RNG kinds. Apply the seed before the stochastic operations whose results you want to reproduce.
Retain the MICE result and, when appropriate, completed datasets, diagnostics, and pooled analysis results.
Compare the generated imputations as well as relevant summaries. Record what was compared and whether the check passed.
Why the Same Seed Can Reproduce a Run
A deterministic RNG can be represented as a state transition. Let \(S_0\) be its initial state after applying the seed. Each request for a random value advances the state and produces an output. Abstractly, if \(T\) is the state-transition rule and \(g\) is the output rule, then successive states and values are
If two runs begin at the same state and apply the same transitions in the same order, induction gives the same state at every step: the states agree at step zero, and equal states produce equal next states under the same transition rule. Therefore, the random values agree as well. If the program uses those values in the same way, its stochastic operations can produce identical results.
This justification depends on matching conditions. A changed data order, a different preprocessing step, altered model specification, or a software change that requests random values differently can change the sequence of requests. Once the streams diverge, later values generally diverge too. Thus, a seed is a reproducible starting point, not a complete description of the computation.
Worked Example: Recording a Fixed-Environment Run
Suppose an analyst plans a hypothetical analysis with 20 imputations and 15 iterations, using a locked R and MICE environment. The analyst chooses seed 48,271 and records the RNG kinds reported by the software. What must be recorded, and what does the seed claim?
The record includes the seed value, 48,271; the reported RNG settings; the R and MICE versions; the input-data identifier; the analysis-code version; the preprocessing; and the MICE settings, including \(m=20\) and 15 iterations. It also records whether the seed was set immediately before the MICE call or supplied through a function argument.
The reproducibility claim is conditional: rerunning the same code on the same input with the same settings and compatible environment is expected to reproduce the same output. The seed does not establish that a different R version, a different RNG configuration, or a modified code path will yield identical completed datasets.
Repeat-Run Checks: Compare Outputs, Not Just Settings
A repeat-run check is an empirical test that a specified workflow behaves as intended. Under strictly matching conditions, exact equality of completed imputed values is a useful check. Also compare important analysis outputs, such as pooled estimates and standard errors, because identical-looking run metadata alone does not establish that the results match. The comparison should reflect the purpose: debugging exact reproducibility is different from assessing whether conclusions are sensitive to Monte Carlo variation.
For exact checks, count the number of entries that differ between corresponding completed datasets, after ensuring that rows, variables, and imputations are aligned. A zero count supports exact equality for the compared entries. If exact equality is not expected, compare estimates and other prespecified summaries, and report the scale and tolerance used. A small numerical discrepancy should not be labelled “identical.”
Worked Example: Exact Comparison of Completed Values
In a hypothetical fixed-environment check, two runs each produce 20 completed datasets. After aligning observations, variables, and imputation numbers, the analyst compares 2,400 imputed cells. The comparison finds no unequal cells. The proportion that differ is
Thus, 0% of the compared imputed cells differ, and the completed values are exactly equal for the cells checked. This supports successful repeatability under the tested conditions. It does not prove that all possible machines or software versions will produce the same values, nor does it assess whether the imputation model is appropriate.
Worked Example: Comparing Pooled Results When Values Differ
Suppose two hypothetical runs under different software environments produce pooled treatment-effect estimates of 1.42 and 1.45 points, with standard errors 0.31 and 0.32 points. The estimate difference is
The relative difference, using the first estimate as the reference, is
These summaries are close, but they are not identical. The analyst should report that the estimate changed by 0.03 points (about 2.11% relative to the first estimate) and the standard error changed by 0.01 points. That comparison alone does not establish that the difference is negligible: its practical importance depends on the outcome scale and the analysis question. Nor does it show that either run is correct. It signals that output identity was not achieved and that the source of the change should be investigated.
What a Seed Does Not Do
Fixing one seed makes a particular random realization repeatable under suitable conditions. It does not remove Monte Carlo variation, guarantee good mixing, validate the imputation models, or make the missing-data assumptions true. A single reproducible run can still have inadequate iterations or other substantive problems. Standard MICE diagnostics and the scientific assumptions of the analysis remain necessary.
A different seed may produce different imputed values even when the procedure is correctly implemented. This is not, by itself, evidence of a software error. For reproducibility, rerun with the same seed and conditions. To investigate variability across random realizations, deliberately run with multiple seeds and compare prespecified quantities; do not silently select the seed giving the preferred result. That is a different objective from reproducing one analysis.
Exact cross-version identity is also not a general promise. Software updates can alter generator defaults, random-number consumption, or implementation details. Even when pooled estimates are close, the completed datasets can differ. State the scope of the reproducibility claim precisely: for example, “exactly reproduced in the recorded environment” is more defensible than “the seed guarantees identical results everywhere.”
Common Mistakes and Diagnostics
| Mistake or warning sign | Why it matters | Correction |
|---|---|---|
| Setting the seed after the MICE call | The call has already consumed random values; the seed did not control that run. | Set the seed before stochastic operations, then rerun and record the placement. |
| Recording only the seed integer | Data, code, RNG settings, or software may differ. | Record the execution context and input and model specifications alongside the seed. |
| Same seed but different imputed values | The runs may differ in row order, settings, RNG configuration, environment, or random-number use. | Check these conditions systematically; do not assume the generator is defective. |
| Calling a run “reproducible” because estimates look similar | Similarity is not exact identity, and no tolerance has been defined. | Specify whether the target is exact values or summary agreement, and report the actual comparison. |
| Changing seeds until a preferred result appears | Seed selection based on the result can undermine the integrity of the analysis. | Choose and document seeds without reference to the desired conclusion; treat multiple-seed checks as a planned assessment. |
If an exact repeat check fails, first verify that the same data and row order were used, then compare preprocessing and MICE settings, RNG settings, software versions, and the point where the seed was set. A discrepancy is a diagnostic signal, not an automatic indication of an invalid analysis. Conversely, a successful equality check verifies repeatability of the tested computation, not the scientific validity of its assumptions.
Check Your Understanding
Answer each question, then compare with the brief solutions.
- An analyst sets a seed only after calling the MICE function. Did that seed control the completed datasets from the call? What should be changed?
- Two runs differ in 6 of 1,500 compared imputed cells. What percentage differ, and can the runs be called exactly identical?
- Name at least four items, besides the seed value, that help make a MICE run reproducible.
- Why can a fixed seed produce identical results in one environment but not guarantee identical imputations across software versions?
- Does reproducing the same completed datasets establish that the imputation model is appropriate? Explain.
Solutions. (1) No. The stochastic call already occurred; set the seed before that call and rerun. (2) \(6/1500\times100\%=0.400\%\). Since at least one cell differs, the runs are not exactly identical. (3) Examples include RNG kinds, software versions, code version, data identifier and order, preprocessing, and MICE settings. (4) Different versions can change RNG defaults or the sequence and implementation of random-number operations, so matching the seed alone may not reproduce the same stream of draws. (5) No. It establishes repeatability under the tested conditions, not validity of the imputation model or its assumptions.