Physical quantities as data

In physics, a number is only useful when you know what it measures, its unit, how it was measured, when/where it applies, and how uncertain it is. A bare 3.2 cannot safely be added to anything; a quantity and a measurement record make the assumptions inspectable.

Think like a programmer

A measurement is an immutable record, not a primitive. Separate a dimensioned quantity from observation metadata: value, unit, uncertainty type/value, instrument/method, calibration or source version, timestamp, conditions, conversion history, and identifier. Use unit-aware constructors for compatible arithmetic, reject invalid/non-finite values, and preserve provenance through reducers and exports. A UI label cannot repair a value whose unit was discarded upstream.

Model checklist

Inputs: Measured value, unit/dimension, uncertainty and coverage/interpretation, instrument/method, calibration/source version, timestamp, environmental/experimental conditions, conversion constants, and record identifier.
State: Immutable measurement record, canonical quantity where appropriate, uncertainty/provenance metadata, and derivation/conversion chain.
Rule: Validate a finite value and compatible unit; convert through named constants when needed; propagate/attach metadata according to the declared calculation rule; retain raw observation beside derived quantities.
Output: Traceable quantity, comparable/non-comparable status, conversion/derivation record, display value, and uncertainty caveat.
Check: Incompatible units cannot be added; converting then comparing preserves physical value within stated conversion precision; records missing unit/source/time are incomplete rather than silently equivalent; changing display format does not alter the record; a derived value names its input records and assumptions.

A useful schema distinguishes quantity from evidence. value: 1.23, unit: "m" describes a physical magnitude; uncertainty and source say how strongly to trust it. Time and conditions matter for a temperature reading, material property, or dynamic measurement. An exact SI-defined constant has a different uncertainty policy from a lab measurement even if both are stored as numbers.

A measurement is structured data

Measured length: 12.4 cm

{
  "value": 12.4,
  "unit": "cm",
  "uncertainty": 0.1,
  "source": "ruler",
  "measuredAt": "2026-09-05"
}

type Measurement = { value: number; unit: "cm"; uncertainty: number; source: string };

Comparability is an explicit result. Two distances can be combined only after compatible units and coordinate/reference conventions are established. Two temperatures may use different scales or sensors; two “mass” records may mean different material samples or different time points. Preserve conversion factors and reference frames, then record whether values are directly comparable, transformable, or incomparable under available metadata.

Try this experiment

Prediction: Changing the displayed value does not change its stated uncertainty, while changing measurement method changes provenance and may change uncertainty.

Create a distance record with value, unit, uncertainty, instrument, source/calibration version, time, and conditions. Format it with different display precision and verify its data record is unchanged. Convert it through a named factor, preserving the conversion record. Replace a ruler with a laser range finder and list which metadata must change before comparing the two observations.

Where this model breaks

A record cannot prove that a measurement was taken correctly. Calibration, sampling bias, systematic error, sensor saturation, reference-frame mistakes, metadata entry errors, and unknown correlations need separate scientific checks. A lightweight unit union catches only supported unit categories; it is not a full dimensional-analysis or uncertainty-propagation system.

Summary

Store enough context to reproduce and interpret a value. Treat quantity, uncertainty, method, source, time, conditions, and conversion history as data; bare numbers are easy to add and easy to misunderstand.

Glossary

Quantity: a value with a unit.
Uncertainty: a stated range of plausible measurement error.
Systematic error: a repeatable bias in a measurement process.
Provenance: record of source, method, and transformations that produced a value.
Comparability: whether two records can support one stated relation under compatible units and conditions.

Self-check

Which fields belong with a measured distance?
Why is source/calibration data useful?
What does uncertainty not tell you?
Why should a derived quantity retain input-record identifiers?

Sources

JCGM, Evaluation of Measurement Data — Guide to the Expression of Uncertainty in Measurement.
NIST, Guide for the Use of the International System of Units (SI).

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 Physical Quantities as Data, write down the quantities you can control, the values your program must retain, and the result a reader could inspect. In Measurement, Units, and Uncertainty, 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 Physical Quantities as Data 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 Physical Quantities as Data into a test

Represent a measurement with its value, unit, uncertainty, source, and time instead of losing meaning in a bare number.

Name the inputs and units that the measurement, units, and uncertainty 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: