Recording and Rerunning the Project

A fitted value is not reproducible evidence unless its origin is recorded. This lesson stores configuration, computed results, environment details, and observations in a structured run record, then reconstructs the configuration and compares a rerun.

A result becomes difficult to trust when its origin is no longer clear. A fitted slope such as 1.95 does not reveal which data, candidate grid, code, or random seed produced it.

A run record preserves the choices and results needed to understand one execution of the project and attempt the same computation again.

Record configuration separately from results

Configuration contains values selected before the run:

seed
point count
x-coordinate range
true slope
noise scale
candidate-slope range and spacing

Results contain values produced by the run:

fitted slope
mean squared error
slope error
largest absolute residual

Keep the groups separate:

This distinction prevents a computed value from being mistaken for a choice. It also makes controlled comparisons easier: configuration explains what changed, while results show what followed.

Preserve every choice that affects the computation

The seed alone does not identify the noisy data. Recreating the same measurements also requires:

  • the input-coordinate rule and range;
  • the number of points;
  • the true slope and intercept assumption;
  • the noise distribution and scale;
  • the order of random-generator operations.

Recreating the same fit additionally requires the candidate range, candidate spacing, loss definition, and tie rule.

If candidate spacing is omitted from the record, another reader might search the same range with different candidates and obtain a different fitted slope. A run record should preserve consequential choices rather than merely the values that are convenient to print.

Use a structured file format

JSON stores nested dictionaries, lists, strings, numbers, Boolean values, and null. It is readable as plain text and can be loaded by another program without parsing custom lines.

indent=2 makes the file easier to read. sort_keys=True gives dictionary keys a stable display order. Neither option changes the meaning of the stored record.

Load it with:

JSON does not directly represent every Python or NumPy object. Convert NumPy scalars to Python values with float(...), int(...), or .item(). Convert arrays to lists only when the values themselves need to be stored.

Give the record a version

A saved record may outlive the current program. Include a small format version:

"record_version": 1

If a later program changes field names or structure, it can inspect this value before interpreting the file. The version describes the record format; it is not the chapter number or Python version.

A project or code version is a separate field:

"project_version": "noisy-line-v1"

In a larger repository, this could be a release number or source-control commit identifier. Its purpose is to identify the implementation that produced the record.

Record relevant environment details

Numerical results can depend on software versions. Record at least the Python and NumPy versions used by this project:

This information does not guarantee reproducibility. Hardware, operating system, library implementations, and other dependencies can also matter in larger computations. It does, however, provide useful evidence when two runs unexpectedly differ.

Do not store secrets, access tokens, or unnecessary personal information in a run record.

Add an observation supported by evidence

A short observation records what the numerical and visual inspection showed:

The fitted slope is close to the generating slope. Residuals are small
relative to the y range and appear on both sides of zero.

Avoid vague judgments such as "the result looks good". Name the evidence and its limit:

The fitted line follows this small synthetic dataset. This run does not test
predictions on unseen data.

An observation is interpretation, not configuration or a computed result. Store it under its own field.

Save one complete run

The example below generates data, fits the slope, constructs a structured record, writes it to JSON, and reads it back. Change one configuration value and inspect which sections of the record change.

Write and load a complete project record

The JSON file separates choices, computed results, environment details, and a written observation.

Ready to run.

The arrays are not stored in this small record because the configuration and code can regenerate them. In a real project, preserve raw data or a stable dataset identifier when the source data cannot be recreated from configuration.

Files in Browser Python

The example writes into the browser Python runtime's temporary file system. Refreshing or closing the page may remove the file, and it is not automatically saved to your device or synchronized with your account. The code demonstrates ordinary Python file operations; use a local Python project when you need the record to persist.

Rerun from the saved configuration

Reconstruct the configuration from the loaded dictionary:

The ** operator passes dictionary entries as keyword arguments. The field names in the saved configuration must therefore match the dataclass parameter names.

Run the same implementation:

Then compare:

Under the same code and numerical environment, this project should reproduce the same arrays and selected slope. np.isclose is still a useful comparison for computed floating-point summaries.

Diagnose a rerun that differs

If a rerun changes unexpectedly, compare in dependency order:

  1. record and project versions;
  2. configuration fields;
  3. Python and library versions;
  4. generated x;
  5. generated y;
  6. candidate slopes;
  7. candidate losses;
  8. fitted result.

Stop at the first difference. A changed fitted slope may be only a downstream effect of changed data or candidates.

Not every project promises bit-for-bit equality across every machine and software version. State which comparisons are expected to be exact and which may require a tolerance.

Exercise: Identify what is needed to recreate noisy data

Which record is sufficient evidence for attempting to recreate this project's noisy measurements?

Choose the useful record

Select one choice, then check.

HintList every dependency of y

The measurements depend on x, the true line, the generated noise, and the implementation that combines them.

SolutionPreserve the complete generating process

Record the seed together with the coordinate rule, point count, line parameters, noise distribution and scale, code, and relevant environment. The seed alone does not state which draws were made or how they became data.

Exercise: Classify a saved field

Where should fitted_slope appear in the run record?

Choose the record section

Select one choice, then check.

HintUse the before-and-after rule

Ask whether the value is known before noisy data is generated.

SolutionThe fitted slope is a result

Store fitted_slope under results. The candidate grid belongs to configuration, but the selected candidate is computed by the run.

Exercise: Preserve the candidate grid

A record saves candidate_start=1.0 and candidate_stop=3.0 but omits candidate_step. What important information is missing?

Choose the missing information

Select one choice, then check.

HintCompare coarse and fine searches

Steps 0.5 and 0.01 cover the same endpoints but evaluate different slopes.

SolutionSpacing defines the candidate values

Without candidate_step, the rerun cannot reconstruct the exact grid. Different candidate values can produce a different selected slope and loss.

Exercise: Write an evidence-based observation

Which observation is most useful in a run record?

Choose the observation

Select one choice, then check.

HintName evidence and a limit

A useful observation should be more specific than approval and less certain than an unsupported proof claim.

SolutionDescribe what was inspected

The first statement names the residual pattern and its scale, then limits the conclusion to the data that was actually inspected.

Exercise: Reconstruct and compare a recorded run

Complete the program so it rebuilds RunConfig from the loaded dictionary, reruns the deterministic calculation, and compares the result. It must print:

same result: True
recorded total: 20

Rerun from saved configuration

Ready to run.

HintUnpack the saved keyword arguments

Unpack the saved configuration dictionary into RunConfig, then pass the reconstructed object to run.

SolutionRecreate inputs before comparing outputs

Dictionary unpacking rebuilds the configuration with the same named fields. The rerun produces 2 + 4 + 6 + 8 = 20, which matches the stored result.

Preserve the chain from choices to evidence

A useful run record answers:

Which implementation ran?
Which values were chosen?
Which environment executed it?
Which results were computed?
What did inspection show?
Which limitations remain?

Rerunning begins with that record, reconstructs the computation, and compares intermediate values before the final result. This makes a difference traceable rather than mysterious.