Computational arrow of time

The computational arrow of time is the direction created by state updates, data recording, memory limits, and modeled dissipation. Every simulation advances a present state to a next state, but that alone does not establish a physical arrow of time. The code may discard information through rounding, sampling, filtering, compression, logging choices, or an irreversible boundary rule. Good simulations make each of those choices inspectable.

Think like a programmer

Store a replay packet, not merely a screenshot: immutable initial state, parameters with units, update-rule and dependency version, integrator and time step, random seed and generator algorithm, boundary policy, machine/precision policy where relevant, snapshot schedule, and every intentional lossy transform. Keep raw state, derived diagnostics, and rendered data as separate layers. Reproducibility lets a reader separate what the model predicts from what the pipeline threw away.

Model checklist

Inputs: Initial state, parameter/unit set, source code/model version, dependency versions, seed and random-generator policy, update rule, integrator, step schedule, boundary policy, snapshot/export schedule, and loss annotations.
State: Timestamped trajectory, checkpoints, random-state position, derived diagnostics, render payload, provenance record, and recovery-error ledger.
Rule: Advance from a serializable state under the recorded update; checkpoint before lossy stages; replay with identical inputs; compare state or named diagnostics at fixed times.
Output: Reproducible trajectory/diagnostic trace, replay comparison, versioned provenance packet, and list of information discarded by each stage.
Check: Same packet reproduces deterministic diagnostics within stated precision; replay divergence identifies first mismatched checkpoint; changing only the seed changes only stochastic outcomes; a no-loss reversible reference recovers compatible state within tolerance; every lossy export/filter/rounding stage has a declared reason and observable effect.

Determinism is an operational promise: same compatible software, inputs, arithmetic rules, and update order give the same output. A random simulation can still be reproducible if its generator algorithm and seed are part of the packet. A parallel reduction, browser GPU path, or library update may change floating-point order and therefore a chaotic trace; record enough environment detail to interpret that difference rather than calling it mysterious physics.

Snapshots are not neutral. Saving every tenth time step loses intermediate transitions; histogramming removes particle identity; quantizing positions loses precision; producing a video loses full state. These may be sensible outputs, but each creates a different observation layer. Keep the raw-state retention policy and derived-data recipe so a reader can rerun a plot rather than infer data from pixels.

Try this experiment

Prediction: A simulation without its seed, version, initial state, and update policy cannot be audited as an experiment; a replay mismatch becomes localizable when checkpoints exist.

Write the smallest replay packet for one published visual. Run a deterministic reference twice and compare a named diagnostic at fixed timestamps. Introduce one controlled loss—round a saved coordinate or reduce snapshot frequency—and record what cannot be reconstructed. Add checkpoints, then identify the first checkpoint that differs after changing one update rule.

Where this model breaks

Storage limits force tradeoffs, and deterministic replay does not prove a physical model is complete. It only makes the computation accountable. Hardware, parallel execution, compilers, random-number algorithms, GPU precision, and external input streams can prevent bitwise replay. Physical irreversibility requires its own system, reservoir, coarse-graining, and statistical evidence; provenance cannot supply it after the fact.

Summary

Make time-directed computation reproducible: preserve an executable replay packet, separate raw state from derived/rendered layers, annotate every loss, and use checkpoints to compare replayed diagnostics. Treat provenance as evidence about computation, not a substitute for physics.

Glossary

Replay: rerun from saved inputs.
Provenance: record of how a result was produced.
Deterministic: identical inputs yield identical outputs.
Checkpoint: saved named state/diagnostic used to localize a replay mismatch.
Loss ledger: record of intentionally discarded or coarsened information.
Self-check
1. What should a replay packet include beyond an initial state?
2. Why must a seeded run record the generator algorithm too?
3. Which display/export operations can make a trajectory impossible to recover?
4. What does computational reproducibility not prove about physical irreversibility?

Sources

D. L. Donoho, An Invitation to Reproducible Computational Research.
V. Stodden, F. Leisch, and R. D. Peng, Implementing Reproducible Computational Research.

Model contract

Treat the lesson as a small function before treating it as a fact to memorize. Give every value a unit, keep only the state needed for the next step, and make the output easy to inspect.

\[\text{observable output} = f(\text{inputs},\,\text{state})\]

Inputs: Quantities you set or measure, with units and useful bounds.
State: Values the program must retain to reproduce the next result.
Rule: The relationship or update that turns inputs and state into a result.
Check: A known limit, unit check, invariant, or measured result that can expose a bad model.

Implement the idea as a model

For Computational Arrow of Time, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Entropy and the Second Law, the useful program is not the drawing: it is the smallest explicit model that makes a prediction you can test.

Guided experiment

Prediction: changing one declared input while holding the others fixed should change only the outputs that the model connects to that input. Choose one input, predict the direction of change, then check a limiting case such as zero, a symmetric arrangement, or a familiar low-speed or small-change approximation.

Where this model breaks

This lesson is a teaching model, not a complete simulator. Before using it outside the stated question, check which interactions, scales, uncertainties, boundary conditions, and measurement limits it leaves out.

Summary

Treat Computational Arrow of Time as a contract: named inputs and units enter a rule, the rule produces an observable result, and a known limit or invariant checks whether the implementation deserves trust.

Glossary

Input: a measured value or chosen parameter supplied to a model.
State: the smallest set of values needed to continue or reproduce a model.
Validation: comparing an output with a known result, limit, invariant, or measurement.

Self-check

Which values are inputs, and which values must remain state?
What observable result would tell you the model is behaving as expected?
Which assumption would you test first before applying the model to a real system?

Model review: turn Computational Arrow of Time into a test

Make simulation time evolution auditable with replay metadata, snapshots, and loss annotations.

Name the inputs and units that the entropy and the second law model needs.
Separate the state you must keep from values you can calculate when needed.
Write one rule that maps the current state and inputs to an observable result.
Choose a limiting case, unit check, invariant, or known result before trusting an output.
State one assumption you would change before using this simplified model for a real decision.

Share to: