SI units as data types

The number 3 is not enough to describe a physical measurement. 3 m and 3 s are different kinds of value, much as a string and a number are different kinds of value in a program.

Think like a programmer

Units behave like lightweight runtime types. Addition needs matching units. Multiplication creates a new unit. A type check cannot decide whether you measured the right object, but it can stop a category error.

Model checklist

Inputs: Numbers and their SI units.
State: A measurement object containing value and unit.
Rule: Only add values with matching units.
Output: A new quantity or a clear error.
Check: 3 m + 2 m equals 5 m; 3 m + 2 s is rejected.

const distance = quantity(3, "m");
const extraDistance = quantity(2, "m");
add(distance, extraDistance); // { value: 5, unit: "m" }

Unit-aware addition

Try to add 3 of one unit to 2 of another. A useful program rejects a nonsense operation before it becomes a plausible-looking number.

3 2

5 m

Try this experiment

Prediction: Changing one selector to seconds will produce an error instead of a sum.

First add metres to metres. Then add metres to seconds. Read the error as a failed function precondition, not as a problem that a calculator should silently fix.

Where this model breaks

This small helper covers only a few units and simple addition. A complete unit system must track compound dimensions, conversions, and measurement uncertainty. It is still safer than stripping units off at the UI boundary.

Summary

Carry units with values. Check unit compatibility before arithmetic and keep the error understandable enough to find the wrong input.

Glossary

SI: the International System of Units.
Dimension: the physical kind of a quantity, such as length or time.
Precondition: a rule that must be true before a function runs.

Self-check

Why is 3 + 2 incomplete in a physics program?
Which operation must reject metres plus seconds?
What extra work does a full unit system need?

Sources

BIPM, 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 SI Units as Data Types, 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 SI Units as Data Types 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 SI Units as Data Types into a test

Treat units like type information so your physics code can accept meaningful arithmetic and reject nonsense.

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: