Introduction
A seed is often treated as if it were a complete recipe for repeating a stochastic analysis. It is not. A fixed seed can initialize the same pseudo-random number stream, yet a changed software version may consume that stream differently, a reordered step may use its values for different purposes, or different hardware may alter floating-point calculations. In a single-cell workflow, these differences can change a dropout mask, a latent-variable draw, or the final fitted representation.
The central distinction is between repeating an initial condition and repeating the whole computation. The earlier material on Seed Management for Stochastic Analyses covers choosing and recording seeds. Here the focus is why that practice alone does not ensure identical outputs.
What Reproducibility Can Mean
“Reproducible” may refer to different levels of agreement. Bitwise reproducibility means every saved output has exactly the same bits. Numerical reproducibility allows small numerical differences within a stated tolerance. Statistical reproducibility means repeated runs give results with similar distributions or scientific conclusions, even if individual random draws and fitted values differ. These are not interchangeable: two runs can be statistically similar but not bitwise identical.
For a stochastic computation, write the output as a function of both random values and the rest of the computation:
where \(U_1,\ldots,U_m\) are values generated from the PRNG and \(C\) collects software, settings, input data, execution order, and numerical environment. A seed can reproduce the \(U\)'s under fixed generator conditions; it does not by itself fix \(f\), \(m\), or \(C\). If a changed implementation consumes one additional value before producing \(Y\), later stages may receive different values even when the initial stream is unchanged.
Exact repetition therefore depends on a collection of conditions: the same inputs and parameters; the same PRNG family and relevant version; the same initial generator state; the same order and number of random calls; the same mapping from random values to outcomes; and deterministic numerical operations executed compatibly. Failure of any one condition can explain differing output. Not every analysis needs bitwise identity, but the target level should be stated and checked rather than assumed.
Worked Example: An Extra Draw Shifts a Latent-State Sample
Suppose a hypothetical PRNG, initialized with a recorded seed, produces the sequence \(0.12, 0.81, 0.34, 0.67,\ldots\). A routine samples one latent category per cell using probabilities \(P(A)=0.2\), \(P(B)=0.5\), and \(P(C)=0.3\). It uses inverse-CDF sampling: values below 0.2 select A, values from 0.2 up to 0.7 select B, and values at least 0.7 select C.
In the first implementation, the routine uses the first three values directly for three cells. The assignments are \(0.12\to A\), \(0.81\to C\), and \(0.34\to B\). Thus the category sequence is A, C, B.
Now suppose a revised preprocessing step uses one random value for a stochastic tie-break before the category routine. The category routine begins with \(0.81,0.34,0.67\), so the three assignments become C, B, B. The seed and PRNG stream are unchanged, but the values are aligned to different operations.
The change does not imply that either implementation has incorrect marginal sampling probabilities. It shows that equal seeds do not guarantee equal per-cell draws when random-number consumption or call order changes. A useful diagnostic is to compare generator states or log the number and purpose of random calls at stage boundaries, where the software permits it.
Software Changes Can Change the Mapping
Even if a routine receives the same uniform random values, it can convert them into outcomes differently. Implementations may use inverse-CDF sampling, a rejection sampler, or an alias method. These can all be valid ways to produce the same target distribution, but they need not assign the same outcome to a particular uniform value. A software update can therefore preserve the intended distribution while changing individual samples.
Worked Example: Two Valid Categorical Samplers
Consider probabilities \(P(A)=0.2\), \(P(B)=0.5\), and \(P(C)=0.3\). In inverse-CDF sampling, a uniform value \(u=0.10\) selects A, because \(0.10<0.20\).
A valid alias sampler first chooses one of three columns uniformly, then uses a second uniform value to decide whether to return that column's category or its alias. The scaled probabilities are \(3(0.2)=0.6\), \(3(0.5)=1.5\), and \(3(0.3)=0.9\). One valid table is:
| Column | Return the column category with probability | Otherwise return |
|---|---|---|
| A | 0.6 | B |
| B | 1.0 | B |
| C | 0.9 | B |
To verify the table, A is returned with probability \((1/3)(0.6)=0.2\), and C with probability \((1/3)(0.9)=0.3\). B is returned either from column B or as an alias:
For example, let \(u_1=0.10\) choose the column by dividing the unit interval into three equal parts; it selects column A. Let \(u_2=0.80\) decide whether to return A or its alias. Since \(0.80>0.6\), the result is B. Inverse-CDF sampling with \(u=0.10\) returned A, whereas this alias procedure returned B. Both methods have the stated category probabilities. The same seed does not imply the same sampled category if the software changes the sampling algorithm or its random-value mapping.
This distinction matters in single-cell workflows that include stochastic subsampling, data augmentation, dropout simulation, or latent-variable sampling. A changed package version might also alter an internal default, such as the generator family, or change when a routine requests random values. Recording only the seed cannot identify these changes.
Execution Order and Floating-Point Arithmetic
Execution order matters even when the PRNG implementation is unchanged. If a workflow runs steps in a different order, or one step makes a different number of random calls, the stream positions assigned to later operations can shift. This is a reason to record the workflow and relevant settings alongside the seed. Hardware and numerical libraries introduce another issue: arithmetic in computers is performed with finite precision, so some algebraically equivalent calculations can produce slightly different results.
A short justification makes the issue clear. In exact arithmetic, addition is associative: \((a+b)+c=a+(b+c)\). Floating-point arithmetic rounds intermediate results, so this equality need not hold. For example, if the magnitude of \(10^{16}\) is large enough that adding 1 is rounded away, then the two orders below differ:
In the second expression, \((-10^{16})+1\) rounds to approximately \(-10^{16}\), leaving a sum of zero. The example is deliberately simple, but it illustrates why reductions over many values can differ slightly across implementations or hardware. The differences may be inconsequential, or they may be amplified by later steps such as iterative optimization, thresholding, or assignment to clusters. This is not evidence that a specific hardware result is wrong; it is evidence that numerical equality should not be presumed.
Worked Example: A Small Numerical Difference Changes a Thresholded Label
Suppose a hypothetical embedding routine assigns a cell to cluster 1 when a computed score is at least 0.5000000, and to cluster 2 otherwise. One hardware and software combination calculates a score of 0.5000001; another obtains 0.4999999 after a different floating-point reduction. Both scores are close, but the labels differ because they lie on opposite sides of the threshold.
The absolute score difference is:
Thus, the assignment difference is not evidence of a large change in the underlying score. It does mean the hard label is unstable at this boundary. To diagnose it, compare the unthresholded scores and their precision, check whether the decision rule was applied identically, and identify cells near the threshold. If the scores differ substantially rather than only near a boundary, the cause may be more than ordinary rounding and deserves investigation.
A Practical Diagnostic Sequence
When a fixed-seed rerun differs, first determine what kind of difference occurred: changed random draws, small numerical drift, or a changed high-level result. Then compare the conditions that control each possibility. The following sequence helps separate causes without assuming the seed is at fault.
Check input identity, preprocessing choices, configuration values, and cached outputs. A seed cannot make two different inputs equivalent.
Record package and runtime versions, PRNG family or kind where exposed, and sampling-method changes. A version label alone may not fully identify a generator implementation.
Compare saved intermediate outputs in workflow order. If random samples first differ, investigate call order and consumption. If continuous values first differ slightly, investigate numerical operations and tolerances.
Record processor or accelerator, relevant numerical libraries, and deterministic-operation settings. Compare raw continuous quantities before interpreting changed labels or clusters.
Decide whether the workflow requires exact output identity, bounded numerical agreement, or comparable scientific conclusions, and validate results at that level.
A fixed seed remains useful: it makes a run easier to repeat under a specified environment and helps isolate sources of variation. It is not a substitute for version control, environment records, input provenance, or saved intermediate artifacts. If an analysis requires exact continuation, preserving the complete generator state can be more informative than storing only its initial seed, though state alone still does not control software or arithmetic changes.
Common Pitfalls and Limitations
- Wrong reasoning: “The seed is unchanged, so any difference must be a bug.” Correction: valid changes in a sampler, call order, or floating-point reduction can alter outputs. Locate the first divergence and identify its type.
- Wrong reasoning: “The random-number generator is the same, so every stochastic outcome must match.” Correction: the same stream can be consumed or transformed differently. Record relevant calls, methods, and versions.
- Wrong reasoning: “A changed cluster label proves the whole embedding changed substantially.” Correction: inspect continuous values and decision boundaries; small numerical changes can flip a thresholded assignment.
- Limitation: Exact bitwise reproducibility across different hardware and software stacks may be expensive or unavailable. Numerical tolerances and scientifically meaningful stability checks may be more appropriate, but they should be defined before interpreting the comparison.
- Limitation: Matching outputs in one test run does not prove that all stages are reproducible. Checks should cover important intermediate artifacts and stochastic components, not only a final summary.
Check Your Understanding
Answer each question, then compare your reasoning with the solutions.
- What conditions, in addition to the same seed, are needed to expect the same stochastic draws?
- A new software version inserts a random tie-break before latent-state sampling. Why can downstream samples change even if the PRNG stream is identical?
- For the alias table above, verify the probability of returning B by adding the contributions from all three columns.
- Why might two scores that differ by only 0.0000002 produce different cluster labels?
- Name one reason to report whether a reproducibility claim is bitwise, numerical, or statistical.
Solutions. (1) The generator algorithm and implementation, initial state, call order and count, mappings from random values to outcomes, inputs, settings, and relevant numerical computation must also match. (2) The tie-break consumes a stream value, so subsequent operations receive later values than before. (3) \(P(B)=(1/3)(0.4)+(1/3)(1.0)+(1/3)(0.1)=0.5\). (4) The scores can fall on opposite sides of the assignment threshold, so a tiny numerical difference changes the discrete label. (5) These terms specify what agreement is expected: exact bits, values within a tolerance, or comparable distributions or conclusions.