Dimensional analysis with code

Before asking whether a result is numerically plausible, ask whether its units could possibly be right. Dimensional analysis is an inexpensive contract: a value may vary at runtime, but a relationship such as speed times time must always return a length. A unit label added only in a chart cannot catch an earlier invalid calculation.

Think like a programmer

Represent quantities as finite values plus declared units/dimensions at API boundaries. Use typed or runtime-validated constructors for compatible addition and named conversion functions for different unit scales. Keep conversions, constants, and reference conventions in provenance. Check dimensions before interpreting values, but do not mistake a lightweight unit union for a complete symbolic algebra system or physical validation.

Model checklist

Inputs: Dimensioned values, selected unit system, conversion constants and source/version, equation/operator, reference-frame or angle convention where relevant, and output unit policy.
State: Validated quantity records, normalized/canonical values when needed, conversion provenance, inferred/result dimension, and rejected-operation diagnostics.
Rule: Apply only dimensionally compatible addition/subtraction; multiply/divide/power dimensions under a declared algebra; convert through named factors before comparing; format after calculation.
Output: Quantity result with unit, dimensional-reduction trace, conversion record, and invalid-operation error where appropriate.
Check: Speed times time reduces to length; force times distance reduces to energy; incompatible addition is rejected; converting then comparing preserves physical value within conversion precision; a dimensionless value is not automatically an angle or a probability; every literal physical constant has a unit/source.

\[d=vt\]

Dimensions are part of the contract

Speed: 5 m/s

5 m/s × 4 s = 20 m

Dimensional reduction is a debugging sequence. Reduce the equation before inserting values, then check limiting cases and signs. For example, kinetic energy must reduce to kg m squared per s squared, which is a joule. A result with correct dimensions may still have an incorrect factor, direction, boundary condition, reference frame, or force law; unit checks narrow the bug search but cannot establish a model.

Angles need a convention. Radians are dimensionless in SI algebra but treating every dimensionless number as an angle is a type mistake. Likewise, probabilities, strains, refractive indices, and normalized residuals can all be dimensionless yet require different valid ranges and meanings. Keep semantic type/convention beside raw dimension where the API needs it.

Try this experiment

Prediction: Doubling speed while holding time fixed doubles distance.

Set speed to 5 m/s and then 10 m/s. Confirm the value and reduce units symbolically before looking at the number. Then reduce the units of force times distance and compare with energy. Try to add a length to a time and state where the code should reject it. Finally name a dimensionally valid but physically false equation that would need a separate model test.

Where this model breaks

A dimensionally valid equation can still be physically false. Dimensional checks catch one class of bug; they do not choose the right force law, validate a measurement, manage uncertainty, prove an SI conversion constant was applied correctly, or detect semantic confusion among dimensionless quantities. Full unit algebra may be costly or incomplete in a teaching application, so document its supported coverage.

Summary

Treat units as part of an equation's contract. Check dimensions and conversions before interpreting the final number, preserve semantic conventions/provenance, and pair unit checks with independent physical-model tests.

Glossary

Dimension: a base physical kind such as length, time, or mass.
Dimensional consistency: both sides of an equation reduce to the same dimensions.
Conversion provenance: named factor/source used to map a quantity between unit scales.
Semantic dimensionless value: dimensionless quantity whose meaning still constrains valid use.

Self-check

What unit results from m/s multiplied by s?
Can a dimensionally consistent equation still be wrong?
Why can a radian and a probability need distinct semantic checks?
Where would you put a dimensional check in code?

Sources

BIPM, The International System of Units (SI).
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 Dimensional Analysis with Code, 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 Dimensional Analysis with Code 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 Dimensional Analysis with Code into a test

Use unit dimensions as executable checks for familiar equations before trusting a numerical result.

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: