Saving Experiment Results

Save enough information to identify what a randomized run did and what it produced. Record the seed, important settings, measurements, and output together in a stable format while keeping large data or model artifacts under separate names.

A printed result disappears when its terminal or browser session ends. A plot without its settings cannot explain how it was made. A number such as 0.842 is difficult to interpret later unless the run, measurement, and data behind it can be identified.

Saving an experiment result means preserving enough evidence to answer:

What computation ran?
Which inputs and settings affected it?
Which randomized choices were used?
What outputs and measurements were produced?
Where are larger artifacts such as data files, figures, or models?

The useful unit is not one isolated number. It is a result record that gives the number context.

Separate configuration, measurements, and artifacts

Three kinds of information commonly belong to a run:

Configuration describes choices known before the computation, such as a seed, sample size, split fraction, or number of trials.
Measurements are small values computed by the run, such as a mean, error, count, duration, or final score.
Artifacts are larger outputs, such as a generated dataset, saved figure, prediction array, or model file.

A compact result record can refer to an artifact rather than embedding its complete contents:

This record states what was requested, what was observed, and where a related figure can be found.

Do not save every temporary variable. Save the information needed to interpret, compare, or rerun the computation.

Use stable names and explicit units

Names such as value, result, or score provide little meaning after the surrounding code is gone. Prefer names that identify the quantity:

Include units in the field name or accompanying metadata when the unit is not obvious. A response time of 18.4 could mean seconds, milliseconds, or microseconds.

Record the definition of a custom measurement when its name is not standard. For example, if error is computed as target - prediction, preserve that sign convention.

Convert NumPy values before writing JSON

JSON is useful for small structured records because it supports objects, arrays, numbers, strings, Boolean values, and null. Python's json module can write ordinary Python values:

NumPy arrays and many NumPy scalar types are not directly JSON serializable. Convert them first:

array.tolist() converts an array to nested Python lists.
scalar.item() converts a NumPy scalar to the corresponding Python scalar.

For a large array, saving every value inside JSON is inefficient. Save the array in an appropriate data format and put its filename, shape, and data type in the result record.

Write and read back one record

Saving is incomplete until the file can be read and its important fields can be checked. Run the example, change the seed or trial count, and inspect the JSON text.

Save and verify a simulation result

The program records configuration and measurements, converts NumPy values to Python values, writes JSON, and reads the file back for verification.

Ready to run.

The equality check confirms that the JSON round trip preserved this record. It does not prove that the computation was correct. Numerical assertions and tests must still check the experiment's logic.

Understand files created by Browser Python

The runnable editor uses Python inside the browser. A file written there belongs to that browser Python environment; it is not automatically saved in your computer's ordinary project directory. Reloading the runtime or clearing site data may remove it.

When the same program runs as a local script, the relative filename refers to the script's current working directory. A production experiment should write to an intentional output directory and preserve or upload the resulting files through the surrounding application.

The lesson's file operations teach the structure of saving and loading. Do not treat the browser runtime as durable experiment storage.

Avoid silent overwrites

Opening an existing filename with mode "w" replaces its previous contents. The short name "result.json" therefore risks destroying evidence from an earlier run.

Use a unique run identifier and derive related filenames from it:

The identifier should distinguish runs that need to coexist. It may contain a timestamp, sequence number, configuration label, or externally assigned ID. Do not rely on the seed alone: two runs can use the same seed with different data, code, or settings.

Before writing, decide whether an existing file should cause an error:

For a deliberately updated record, use a documented replacement policy rather than accidental overwriting.

Record versions and data identity when they matter

A seed cannot reproduce changed code or changed inputs. A stronger record may include:

In a maintained project, a source-control commit identifies code more reliably than copying source text into every result:

result["code_revision"] = "project-commit-id"

Use the identifiers available in the project. The principle is to distinguish the exact inputs and implementation needed for comparison.

Do not store secrets, passwords, access tokens, or unnecessary personal data in experiment records. Results are often copied, shared, backed up, or published.

Save a compact preview, not misleading evidence

A short array preview helps identify a run:

"sample_preview": sample[:8].tolist()

It does not replace the complete artifact when later analysis needs every value. State whether a stored array is complete or only a preview.

Similarly, a rounded display value should not silently replace a higher precision measurement:

The numerical field supports comparison; the formatted string supports presentation.

Exercise: Choose a useful result record

Which record gives the strongest context for comparing a randomized run later?

Choose the record

{
"seed": 12,
"sample_count": 500,
"mean_error": 0.27,
"prediction_file": "run-004-predictions.npy"
}

{"result": 0.27}{"status": "looked good"}

Select one choice, then check.

HintAsk what can be compared

A later reader needs more than one unexplained value or judgment.

SolutionRecord configuration, measurement, and artifact identity

The complete record preserves the seed, sample count, named measurement, and prediction filename. It gives the value enough context for a later comparison.

Exercise: Convert a NumPy array for JSON

Which expression converts a NumPy array named residual to a JSON-compatible nested Python list?

Conversion

Answer it first, then check.

HintUse the array conversion method

The method name is tolist.

SolutionCall residual.tolist()

residual.tolist() recursively converts array values into Python lists and scalar values that the JSON encoder can handle.

Exercise: Prevent an accidental overwrite

Which approach best preserves two runs that use the same seed but different sample sizes?

Choose the saving rule

Give each run a unique identifier and derive its filenames from that identifier.Use the seed as the only filename for both runs.Write both records to result.json with mode w.

Select one choice, then check.

HintDistinguish complete runs

Seed and sample size are separate configuration values.

SolutionUse a unique run identifier

Deriving filenames from a unique run ID prevents the later run from silently replacing an earlier result with the same seed.

Exercise: Interpret a browser-created file

A runnable lesson writes result.json successfully. Which statement is correct?

Choose the interpretation

The file belongs to the browser Python environment and is not automatically durable local storage.The file must now exist beside the website's source code on the server.The file is automatically synchronized to the signed-in account.

Select one choice, then check.

HintRecall the execution environment

The Python program is running inside the browser.

SolutionTreat the browser file as temporary runtime data

The write demonstrates file operations, but the resulting file is not automatically placed in a local project or synchronized account store.

Exercise: Write and verify a JSON result

Complete the program so it saves result to the supplied filename and loads it back. The output must include:

seed: 29
sample count: 6
round trip: True

Save a structured experiment record

Ready to run.

HintConvert, write, and read

Add "sample": sample.tolist(), use json.dump inside a write-mode file block, then use json.load inside a read-mode block.

SolutionRound-trip a JSON-compatible record

Converting the array makes the record JSON-compatible. Writing and loading the same structure verifies that its seed, sample count, and sample values survive the round trip.

Retain the result-record method

Before accepting a saved result, check:

run identity
+ explicit configuration and seed
+ named measurements with units
+ artifact references and previews
+ data and code identity when needed
+ environment versions when needed
+ successful read-back
= interpretable experiment evidence

A saved file is useful only when another reader—or your future self—can tell what it represents and connect it to the computation that produced it.