Research May 24, 2018

Dimensional Analysis in Programming Languages

A survey of existing designs and implementations for automatic conversion and verification of units of measurement in computer programs.

Tags: programming

• Overview
• Ada
• ATLAS
• C
• C++
• D
• Eiffel
• Excel
• Fortran
• Fortress
• Frink
• F#
• Haskell
• Java
• Lisp
• Nemerle
• Nim
• Pascal
• Perl
• Python
• Rust
• Scala
• Summary
• Related Resources

Overview

Dimensional analysis is a technique for comparing and calculating with numerical quantities in which units are included and treated algebraically. This article clarifies the basic concepts and looks at how they have been implemented in various programming languages.

Motivation

Opinions differ as to whether dimensional analysis should be implemented as a language feature, a library, or at all. One thing that most engineers do agree on is that there is great value in compilers verifying the correctness of programs before they are executed. The ability to automatically check the usage of units of measurement can eliminate an entire class of errors and potentially prevent all sorts of disasters. What is less clear is how this should be accomplished in practice.

If you’ve used strongly-typed programming languages before, the relationship between dimensional analysis and type theory is rather obvious. Using types to represent measurement systems is in fact the most popular implementation approach, but not everyone agrees that the added structure and complexity is worth the effort. The controversy mainly revolves around convenience. When is a type system beneficial, and when does it get in the way? John D. Cook pointed out that it mainly depends on your use case. It also depends on how expressive the language is and how much machinery is needed to make it work.

I mostly work in large code bases myself. These aren’t necessarily mission critical in the sense that lives depend on them, but reliability still is a desirable property from a business point of view. Other software qualities that are often overlooked are comprehensibility and maintainability. In an economic system that rewards time to market, the long-term costs of software development are rarely considered. By adding dimensional analysis to code we have an opportunity to make it easier to read, understand, refactor and extend. This is increasingly important as projects grow larger over time.

Concepts

Different authors use slightly different terminology in the literature for dimensional analysis, so it might be worthwhile to clarify the concepts.

Physical dimensions (also: dimensions) are distinct kinds of observable characteristics of objects or events that can be directly compared to one another, i.e. length, mass, and electric charge. Even though there is strong agreement about which dimensions form the foundation of the natural sciences, they are nevertheless a matter of convention. For instance, electrical properties were not taken into consideration until the 1800’s.

Measurements are the assignments of numbers (also: measures, values, or magnitudes) to the characteristics of objects or events within a given dimension. Since physical characteristics cannot be described in absolute terms they must be compared by reference to other objects or events. For example, we can determine that some object has the same length as, or twice the mass of another object. The process of measuring can be simple or involved, but the numbers assigned as a result are always ratios of the objects’ characteristics within the dimension of interest.

Base units are characteristics of particular objects or events that are selected as a reference for taking measurements in a given dimension. In practice, most base units are derived from invariant constants of nature that can be measured with great accuracy, but it is important to note that they, too, are a matter of convention. For example, second is the base unit for measuring time in the SI system and defined in terms of radiation properties of Caesium 133 atoms. Base units are chosen in such a way that they cannot be derived (are mutually independent) from each other.

Derived units are defined in terms of base units or other derived units by combining them via multiplication or division. If meter and second are chosen as base units, meter2 and meter/second would be derived units.

Unit exponents (also: exponents) are positive or negative numbers for the powers of base units that make up a derived unit. For example, voltage is derived from the base units kilogram, meter, second, and ampere, and the exponents are 1, 2, -3, and -1 for kg×m2×s−3×A−1. In practice, the vast majority of exponents are in the range -4 to +4, inclusive. Exponents are usually integral, but some computations involve rational exponents.

Units of measurement (also: units, units of measure) are base units or derived units. Physical dimensions may have multiple units, for example, meter and inch are both units of length. Units may contain multiplicative factors, for example, one inch is 0.0254 meters. Units are said to be coherent if they do not contain any numerical factors other than 1. Units may also contain zero point shifts as in celsius and fahrenheit, which are both units of temperature. These are sometimes called affine units.

Unit symbols (also: symbols) are letters or signs assigned to units of measurement so that the latter can be expressed more concisely. For example, in the SI system, m is the symbol for meter (the unit of length), and J (Joule) is the symbol for kg×m2×s−2 (the unit of energy).

Prefix names (also: prefixes) are words added to unit names to produce multiples and sub-multiples (usually powers of ten or a thousand) of the original unit. For example, the SI system defines the standard prefix names kilo for 103 and milli for 10-3, so that kilometer is equal to one thousand meter, and milligram to one thousands of a gram. Prefixes are never combined, i.e. micrometer is used instead of millimillimeter.

Prefix symbols are short versions of prefix names that are attached to unit symbols, for example, k for kilo and m for milli, so that kilometer can be written as km, and milligram as mg.

Physical quantities (also: quantities) are characteristics of objects or events that can be quantified by measurements. They can be represented as a combination of magnitude, usually a real number, and unit. For example, the quantity 1.6749×10−27 kg is the mass of a neutron. Physical quantities that have the same dimension are said to be commensurable and can be directly compared to each other even when expressed in different units of measure. Quantities measured in base units are base quantities. Quantities that do not have a physical dimension associated, such as angles, ratios, or percentages are called dimensionless quantities.

Systems of measurements are sets of units of measurement that form a framework for comparing physical quantities. Such systems may or may not be coherent. The modern SI system was designed to be coherent, but the Centimetre–gram–second (CGS) system is not because it contains calorie as a unit of energy, which is not coherent with its other base units. Systems of measurement may include definitions for unit symbols and prefixes.

Dimensional analysis is the analysis of the relationships between different physical quantities by identifying their base quantities and units of measure, and tracking these as calculations or comparisons are carried out. Historically, it is used to simplify physical problems before obtaining a quantitative answer. In computer programs it can be used to verify the semantic consistency of scientific algorithms.

An important theorem in dimensional analysis is the Buckingham π theorem, which states that the laws of physics do not depend on the choice of a specific system of measurement. One should also note that, even though dimensional analysis is usually associated with scientific calculations and the definitions above rest on examples from physics, it is not limited to physical quantities, but applicable to any kind of units, practical or not.

The theoretical foundations of dimensional analysis and its application in the natural sciences are well explained in Sonin’s paper on The Physical Basis of Dimensional Analysis. In the rest of this article we will take a look at how it is implemented in existing software systems.

Languages

We already considered the use of the type systems of programming languages to represent units of measurement. However, the label notation that is commonly taught in school, and that most of us are familiar with, does not lend itself to the syntactic requirements of most languages. The resulting code can be awkward or cumbersome to use. It is therefore tempting to build syntactic support for dimensions and units into the language itself.

Surprisingly, there aren’t many programming languages that actually do this. At the time of this writing, the only mainstream language with built-in support appears to be F#. The other big contenders are ATLAS, Fortress and Frink. We’ll look at these in more detail below.

Libraries

Many argue that dimensional analysis is a domain specific feature that does not belong into the programming language itself, but is best left to be implemented in libraries. Ideally, a programming language is as concise and general as possible while also providing mechanisms for expressing domain specific concerns in a convenient and readable way.

Even though most of today’s mainstream languages are still significantly handicapped in this regard, there has been no lack of implementation attempts. It is worthwhile to study the most popular libraries and see what they offer, how they differ, and the limitations they have.

Research

Research for the incorporation of units into programming language goes all the way back to the 60’s. A more general discussion has been presented as early as 1978 by Karr & Loveman. After reviewing units calculus, their paper introduces units as sub-types and covers syntactical issues. Much of it is still relevant today.

There have also been attempts to infer unit types automatically without any annotations, such as by Wand & O’Keefe for ML, and Guo & McCamant for C. Bruche Hamilton discussed the general representation of units in and between computer systems.

The following sections will give an overview of particular implementation examples in various programming languages. It is not my goal to provide an exhaustive list and analyze or evaluate each of them in detail, but rather to point out certain design decisions, features, and syntactic choices.

Ada

Dimensional analysis support in Ada has been researched since the mid 80’s, and there have been a number of proposals. Grein et. al. published a survey of physical unit handling techniques in 2003, discussing the contradictory requirements of compile-time methods, as well as the implementation and shortcomings of existing solutions. The problem was solved more generally (and with some compromises) in the GNAT dimension system in 2012.

Gehani

In 1985, N. H. Gehani’s presented two ideas for units of measure in Ada. His first implementation uses distinct derived types in combination with operator overloading:

type SPEED is new FLOAT;
type ACCELERATION is new FLOAT;
type TIME is new FLOAT;
type DISTANCE is new FLOAT;

function "*"(A:SPEED;B;TIME) return DISTANCE is
begin
return DISTANCE(A) * DISTANCE(B);
end "*";

function "*" (A:ACCELERATION; B:TIME) return DISTANCE is
begin
return DISTANCE(A) * DISTANCE(B);
end "*";

U: SPEED;
A: ACCELERATION;
T: TIME;
S: DISTANCE;

S:= U * T + 0.5 * A * (T * T);

Gehani shows that this is approach is not sufficient for modelling an algebra with units as it disallows certain operations that should be permitted and vice versa.

After considering language modifications and preprocessors, his second implementation is a library package that introduces integer and floating-point quantity types that store a unit name and exponent along with values, and a set of operators and helpers for assignments and conversions:

AREA: FLOAT-WITH-UNITS:= (0.0, 1, ((METER, 2)));
SIDE: FLOAT-WITH-UNITS:= (5.0.1. ((METER, 1)));
S1, S2: FLOAT-WITH-UNITS:= (0.0, 2, ((MILE, 1), (HOUR, -1)));

ASSIGN(AREA, SIDE*SIDE);

This notation considerably differs differs from what scientists are acustomed to, and Gehani’s approach also has some other problems. A detailed critique can be found in R. T. House’s proposal for type checking of expressions (PDF).

GNAT

In 2012, Vincent Pucci and Ed Schonberg added support for physical units with simple dimensionality checking at compile-time to AdaCore’s GNAT compiler. The system provides base and derived MKS units and symbols with zero run-time overhead. It has support for fractional dimensions and basic I/O. Prefixed units are represented as constants.

Unit systems are defined via two aspects, Dimension and Dimension_System, which can also be used for defining custom units. The details and some examples are explained in Pucci’s blog post.

The following is an excerpt of the MKS system definition:

type Mks_Type is new Long_Long_Float
with
Dimension_System => (
(Unit_Name => Meter,    Unit_Symbol => 'm',   Dim_Symbol => 'L'),
(Unit_Name => Second,   Unit_Symbol => 's',   Dim_Symbol => 'T'),
...

subtype Length is Mks_Type
with
Dimension => (Symbol => 'm',
Meter  => 1,
others => 0);

subtype Time is Mks_Type
with
Dimension => (Symbol => 's',
Second => 1,
others => 0);

m : constant Length := 1.0;
s : constant Time := 1.0;

cm : constant Length := 1.0E-02;
km : constant Length := 1.0E+03;
min : constant Time := 60.0 * s;
hour : constant Time := 60.0 * min;

subtype Area is Mks_Type
with
Dimension => (
Meter  => 2,
others => 0);

subtype Speed is Mks_Type
with
Dimension => (
Meter  =>  1,
Second => -1,
others =>  0);

The defined units can then be used in program code (excerpt from GNAT):

procedure Foo is
subtype Acceleration is Mks_Type
with Dimension => ("m/sec^2", 1, 0, -2, others => 0);

G : constant Acceleration := 9.81 * M / (S ** 2);
T : Time := 10.0 * S;
Distance : Length;
begin
Distance := 0.5 * G * T ** 2;
Put (Distance, Aft => 2, Exp => 0);
end Foo

The original implementation allowed for generic programming, but left it unchecked for dimensionality correctness. This was later improved by Moy, Becker, and Regnath. Note that identifiers in Ada are case-insensitive, so the above example (M vs. m, S vs. s) still works. This and other minor shortcomings along with suggested improvements were discussed by Grein.

UNITS

In 1988, Paul N. Hilfinger published a paper that demonstrates dimensional analysis in Ada based on Gehani’s approach using the language’s existing abstraction facilities like operator overloading and type parameterization. His UNITS package allows for declaring variables, constants, and parameters with particular units of measure and arithmetic operations between them.

The following code snippet shows the syntax for declaring base unit types, a constant, variables, and function parameters:

subtype DISTANCE is QUANT(i,O,O,O);
subtype TIME is QUANT(O,l,O,O);

GRAVITY : constant QUANT := 980.7 * CM / SEC**2;

x,y : DISTANCE := 0.0 * CM;
V : VELOCITY := 0.0 * (CM / SEC);

function HEIGHT(X : DISTANCE) return DISTANCE is
-- implementation goes here
end HEIGHT;

QUANT is a generic value-with-units type for defining concrete unit subtypes. It uses Ada’s constant folding to evaluate the discriminants at compile-time. It is limited to a total of four integral dimensionalities.

ATLAS

C/ATLAS

One of the early high-level programming languages with support for units is C/ATLAS, which was originally created in 1968 for the automated testing of avionics equipment. It has a fixed set of physical units and operations to model signal flows and common electrical and mechanical systems.

The following statement applies an alternating current of 7.5 volts at 3 kilohertz to a pin called AC SIGNAL:

010200  APPLY, AC SIGNAL, VOLTAGE-PP 7.5V, FREQ 3 KHZ, CNX HI=P1-1 $

ATLAS 2000

After several IEEE standard iterations of C/ATLAS that culminated in IEEE 716-1995, the language was restructured into ATLAS 2000. The signal modelling aspects moved into a new language called SMML. It uses a more familiar syntax, but still doesn’t allow for extending the built-in units.

The following sample declares a voltage input signal and then applies a 20 hertz sine wave at 2 volts and zero phase to it:

inp:: SignalRep Time Voltage
inp = sine(V 2.0)(Hz 20)(Rad 0.0)

There are a total of 41 predefined physical types, each with its own unit. Units always start with an upper-case letter, regardless of physical convention. Some are overloaded with prefixes, i.e. Hz, Khz and Mhz.

C

C is still one of the most widely used programming languages today. Compared to many modern languages, its type system is arguably more limited when it comes to abstraction capabilities. Nevertheless, support for dimensional analysis has been studied and exists via pre-processors.

C-UNITS

In 2003, Grigore Rosu and Feng Chen published a prototype for certifying measurement unit safety policies that is based on Maude, a framework for program specification and verification, and consists of both a static and a dynamic checker. It uses a Maude specification to declare units of measure within the C programming language, and a special /*U U*/ comment syntax for annotating the code.

The following snippet was taken from the paper to demonstrate the annotation of functions and variables:

float lb2kg(float w)
/*U assert unit(w) = lb U*/
/*U assume returns kg U*/
{
return 10 * w / 22;
}

float projectilex, projectiley;

projectilex = 0; /*U assume unit(projectilex) = meter U*/
projectiley = 0; /*U assume unit(projectiley) = unit(projectilex) U*/

The system’s dynamic checker interprets the enriched C program and checks the units of variables when they are evaluated. This adds some storage and run-time overhead. The static checker covers all reachable code, but may generate a large number of false alarms in the absence of annotations.

Guo & McCamant

In 2005, Philip Guo and Stephen McCamant presented a technique for annotation-less type inference for C that automatically assigns and verifies unit types to all of a program’s variables.

One interesting aspect of their tool is that it does not assume any particular unit system, but instead builds up a set of constraints over all variables based on static code analysis. From these, a system with the minimum number of unspecified base units is then constructed. The user may, but is not required to annotate them with more specific names.

This approach has the major advantage that programmers can construct a complete unit typing with a minimal number of annotations. It also allows for verifying the unit correctness of existing programs without modifying the programs themselves.

For example, take the following C program:

int main() {
double mass, velocity, height, kinetic, potential;
/* ... initialize relevant variables ... */

kinetic = 0.5 * mass * velocity * velocity;
potential = mass * height * 9.8;

printf("Total energy is: %g J\n", kinetic + potential);
return 0;
}

Based on the constraints imposed by the addition and multiplication operations in this code, the tool may produce the following results:

Variables:
1: velocity            Units: (unit 1)
2: mass                Units: (unit 2)
3: constant 0.5        Units: (unit 3)
4: constant 9.8        Units: (unit 4)
5: height              Units: (unit 1)^2 * (unit 3) * (unit 4)^-1
6: kinetic, potential  Units: (unit 1)^2 * (unit 2) * (unit 3)

Since the inferred unit names are largely meaningless, the user may annotate them with physics terms, such as:

Variables:
1: velocity            Units: meter second^-1
2: mass                Units: kilogram
3: constant 0.5        Units: dimensionless
4: constant 9.8        Units: meter second^-2
5: height              Units: meter
6: kinetic, potential  Units: kilogram meter^2 second^-2

In practice, only four of the six units need to be annotated, because the tool can infer the derived units automatically. These annotations are then used for human readable error messages when parsing additional code.

Osprey

The Osprey type system adds special unit annotations to C code that are parsed and converted to type constraints and evaluated at compile time. The system focuses on the SI system of measurement and implements the seven base units from which all other scientific units can be derived.

Unit annotations start with a $ character and support superscripts for exponentiation. Some units also have aliases, such as kilogram and kg. The special unit type $unity is used for dimensionless units.

The following code declares a variable ‘length’ with base unit ‘meter’, a variable ‘energy’ with derived units, and a structure containing a dimensionless quantity.

$meter double length;
$kilogram*meter²*second⁻² double energy;

typedef struct {
$kilogram double atomicWeight;
$unity double atomicNumber;
} Element;

A constraint resolution algorithm uses these annotations to verify the correctness of the rest of the program.

Unitc

unitc is a pre-processor written in Haskell with unit annotations in a different syntax. The following is a valid program that declares annotated velocity and time variables and computes an acceleration from them:

double v unit(m/s);
double t unit(s);
double a unit(m/s/s) = v / t;

The current implementation only supports base units. These are not hard-coded, but derived from the annotations. It doesn’t support prefixes or aliases, and the notation for exponentiation is rather limiting.

C++

As might be expected, the template meta-programming features of C++ encouraged a number of compile and run-time dimensional analysis libraries. A search on GitHub reveals over a dozen, and many more can be found on the internet. Most implementations are more or less variations of each other, so we will only look at some representative examples.

Boost

One of the most prominent implementations is Boost.Units. It uses compile-time metaprogramming techniques to implement generic and extensible unit systems that do not incur any run-time overhead.

Like most Boost libraries, Boost.Units is very comprehensive, extremely flexible, and tries to cover all posssible use and edge cases. The library does not only check the validity of unit calculations at compile-time, but also allows for compile-time unit calculations according to dimensional analysis rules inside template meta-programs.

The following lines are excerpts from the definition of a simple meter-kilogram-second unit system:

struct length_base_dimension : base_dimension<length_base_dimension, 1> { };
struct mass_base_dimension : base_dimension<mass_base_dimension, 2> { };
struct time_base_dimension : base_dimension<time_base_dimension, 3> { };

typedef length_base_dimension::dimension_type length_dimension;
typedef mass_base_dimension::dimension_type mass_dimension;
typedef time_base_dimension::dimension_type time_dimension;

typedef derived_dimension<length_base_dimension, 2>::type area_dimension;
typedef derived_dimension<mass_base_dimension, 1,
length_base_dimension, 2,
time_base_dimension, -2>::type energy_dimension;

struct meter_base_unit : base_unit<meter_base_unit, length_dimension, 1> { };
struct kilogram_base_unit : base_unit<kilogram_base_unit, mass_dimension, 2> { };
struct second_base_unit : base_unit<second_base_unit, time_dimension, 3> { };

typedef make_system<
meter_base_unit,
kilogram_base_unit,
second_base_unit>::type mks_system;

typedef unit<dimensionless_type, mks_system>      dimensionless;
typedef unit<length_dimension, mks_system>        length;
typedef unit<mass_dimension, mks_system>          mass;
typedef unit<time_dimension, mks_system>          time;

BOOST_UNITS_STATIC_CONSTANT(meter, length);
BOOST_UNITS_STATIC_CONSTANT(meters, length);
BOOST_UNITS_STATIC_CONSTANT(kilogram, mass);
BOOST_UNITS_STATIC_CONSTANT(kilograms, mass);
BOOST_UNITS_STATIC_CONSTANT(second, time);
BOOST_UNITS_STATIC_CONSTANT(seconds, time);

template<> struct base_unit_info<test::meter_base_unit>
{
static std::string name() { return "meter"; }
static std::string symbol() { return "m"; }
};

template<> struct base_unit_info<test::kilogram_base_unit>
{
static std::string name() { return "kilogram"; }
static std::string symbol() { return "kg"; }
};

template<> struct base_unit_info<test::second_base_unit>
{
static std::string name() { return "second"; }
static std::string symbol() { return "s"; }
};

Unit systems defined in this way may then be used as follows:

quantity<length> L(2.0 * meters);
quantity<energy> E = kilograms * pow<2>(L / seconds);

quantity<length, std::complex<double> > L(std::complex<double>(3.0, 4.0) * meters);
quantity<energy, std::complex<double> > E(kilograms * pow<2>(L / seconds));

const double dimless = (L/L);

Note that scientific calculations can be performed out of the box, because the library already includes complete definitions for the SI and CGS unit systems, supports angle and temperature measurements in various units, and provides fine-grained conversions between them.

For a complete description of all features along with numerous examples check out the official documentation.

cpp-measures

Carlo Milanesi’s cpp-measures is a header-only library for compile-time dimensional analysis using C++ templates. The only pre-defined unit of measure is radians. All others must be defined by the user, for example:

MEASURES_MAGNITUDE(Length, metres, " m")
MEASURES_UNIT(km, Length, " Km", 1000, 0)
MEASURES_UNIT(cm, Length, " cm", 0.01, 0)

The following example code demonstrates the definition and usage of physical quantities, as well as conversions between units:

vect1<mm, double> a(6);
vect1<joules> work = vect2<newtons>(12, 13) * vect2<metres>(3, 5);
vect1<celsius> t = convert<celsius>(vect1<fahrenheit>(90));

Support for vector quantities is built into the library and limited to a maximum of three dimensions:

point3<inches, float> b(7, 8, 9);

This may seem like a surprising design choice at first, but it enables some interesting calculations. For example, it allows energy to be expressed in relation to vector quantities:

vect1<joules> e = vect2<newtons>(12, 13) * vect2<metres>(3, 5);

Note that the * operator is defined as the dot product here.

Dimentia

Dimentia is a system that implements a static analysis pass for LLVM in order to perform consistency checks without requiring any input from the programmer. It does so by associating with each program variable a so called scalar deggree, which is the sum of exponents of a type’s units. These are solely derived from the operations on the variables.

Due to its approach, the system cannot detect semantic errors in isolation, but it can successfully detect confliting usages of variables in larger programs without having to know their intended semantics.

Quantity

Michael Kenniston’s Quantity is a portable header-only C++ template library for compile-time verification of computations with physical quantities. It includes a quantity template type with a fixed set of seven dimensions for modelling the SI system, a comprehensive collection of base and derived units and quantities, arithmetic operations over quantities, SI prefixes, and some support for I/O and unit conversion.

Magnitudes are internally represented as double by default, but the behavior can be overriden with a compiler directive. The following code is taken from the library to illustrate how it defines these aspects:

typedef dimensions<1, 0, 0, 0, 0, 0, 0> length_d;
typedef dimensions<0, 0, 1, 0, 0, 0, 0> time_interval_d;
typedef dimensions<1, 0, -1> speed_d;

inline Rep milli() { return Rep(1e-3L); }
inline Rep kilo() { return Rep(1e+3L); }

inline quantity<mass_d> kilogram()
{
return quantity<mass_d>(detail::permit(Rep(1.0)));
}

inline quantity<mass_d> gram() { return kilogram() / 1000; }
inline quantity<force_d> newton() { return meter() * kilogram() / square(second()); }

The following lines demonstrate the usage of the library:

quantity<length_d> width(1.2f * meter());
quantity<length_d> height(2.3f * meter());
quantity<area_d> area(width * height);
quantity<speed_d> speed = height / second();
quantity<volume_d> vol = cube(height);

double r = width / height;
double s = speed * (second() / meter());

quantity<energy_d> e = 42 * kilo() * watt() * hour();
std::cout << e;  // "42 m+2 kg s-2"

PhysUnits is an adaption of Quantity for C++11. One of the interesting improvements is the added support for user-defined literals, so that quantities can be written more concisely as 1_ns or 42_km.

PhysUnits-CT and PhysUnits-RT are versions of PhysUnits for C++98 and for run-time evaluation. The latter increases the number of supported dimensions to 10 and stores them alongside values:

quantity F(2.0 * newton());
quantity dx(2.0 * meter());
quantity E(work(F, dx));

std::cout << E; // "4 J"

SIunits

Walter E. Brown’s SIunits is a template based C++ library for compile-time checking of physical units. The initial version was introduced in the 1998 paper Introduction to the SI Library of Unit-Based Computation. It has no run-time overhead, includes a large number of pre-defined units, and allows for user defined calibration of base units to accommodate for different precisions/magnitudes.

As a somewhat unique feature, the library also offers five different models for base units to enable calculations from different physical view points, i.e. high-energy, relativistic, or quantum.

The API assumes that values are represented as double, but also allows for custom value types via template parameters.

Length d1(2.5);                   // 2.5 meters; same as 2.5 * m
Length d2(1.2 * cm);              // 1.2 centimeters; recorded as .012 * m
Width d3(1.23 * pico_ * meter);   // 1.23e-12 * m; Width is a synonym for Length

Length d4(d1 + d2);
Area a1(d1 * d2);

Like many other libraries, SIunits encodes a unit type’s dimensions in a 7-tuple that holds the exponent for each dimension. Early implementations used seven integer template parameters, but those were later refined to take a type list of compile-time rational numbers, which permit a broader range of dimensional exponents and cover computations involving roots:

Mass<> m = 100 * kilogram;
Energy<> e = m * c * c;
Velocity<> v = sqrt(e) / sqrt(m);

The implementation details can be found in the 2002 paper Applied Template Metaprogramming in SIunits.

D

The inclusion of dimensional analysis support in the Phobos standard library has been discussed for several years and seems to be an ongoing effort. So far there have been only a couple major community projects.

quantities

Nicolas Sicard’s quantities library supports both compile-time and run-time checking of units of measures and includes a comprehensive set of SI units, unit symbols, and prefixes.

Compile-time support is provided via a Quantity template that wraps a generic scalar value into a struct whose type contains a vector of dimensions. The dimension vector is used to statically check for dimensional consistency, and it has zero storage and run-time overhead:

auto kilometer = kilo(meter);
auto distance = 384_400 * kilometer;
auto speed = si!"299_792_458 m/s";

Time time = distance / speed;

writeln(siFormat!"%.3f s"(time)); // "1.282 s"

For run-time support, the library introduces a generic QVariant type that stores the vector of dimensions in a member field instead, and inconsistent calculations throw an exception:

auto distance = qVariant(384_400 * kilo(meter));
auto speed = parseSI("299_792_458 m/s");

auto time = distance / speed;

writeln(siFormat!"%.3f s"(time)); // "1.282 s"

To some extent, Quantity and QVariant can be used together in the same expression. The parser used to read quantities from strings is extensible.

std.units

David Nadlinger’s std.units (GitHub) is a library for compile-time checking of units of measurements. It does not define any system of measurement out of the box, but provides a set of mixins for creating user defined base, derived, scaled, and affine units:

alias BaseUnit!("Ampere", "A") Ampere;
enum ampere = Ampere.init;
// or
enum ampere = baseUnit!("Ampere", "A");

alias DerivedUnit!(
BaseUnitExp!(Ampere, Rational!1),
BaseUnitExp!(Second, Rational!1)
) Coulomb;
enum coulomb = Coulomb.init;
// or
enum coulomb = ampere * second;

alias ScaledUnit!(Metre, 0.0254, "inch", "in") Inch;
// or
alias ScaledUnit!(metre, 0.0254, "inch", "in") Inch;
// or
enum inch = scale!(metre, 0.0254, "inch", "in");

enum celsius = affine!(273.15, "degrees Celsius", "°C")(kelvin);

The unit dimensions are encoded into the types. Prefixes are implemented as templates and helper functions that can also be generated automatically:

alias PrefixSystem!(10, { return [
Prefix(-3, "milli", "m"),
Prefix(3, "kilo", "k")];
}) System;

alias prefixTemplate!(-3, System) milli;
alias prefixTemplate!(3, System) kilo;

The following are usage examples for code with units:

enum squareMetre = pow!2(metre);
enum celsius = affine!(273.15, "degrees Celsius", "°C")(kelvin);

Quantity!(metre, int) x = 6 * metre;
auto speed = x / second;
assert(l / metre == 6 * dimensionless);

auto il = cast(Quantity!(metre, int))x;
auto a = pow!2(5 * metre);

With the units-d library, Per Nordlöw attempted to combine std.units with the expression parsing capabilities of quantities.

Eiffel

EiffelUnits

EiffelUnits is a library for the Eiffel programming language that allows for attaching units to quantities. It includes a set of common scientific units, but can be extended with user defined unit types. The following code snippet declares a constant for gravitational acceleration:

Gravity: QUANTITY is
-- gravitational acceleration on earth surface
once
Result := quantity (9.81) * m / (s ^ 2)
ensure
Result.has_dimension (dim.Acceleration)
end

QUANTITY is a generic type that can hold any combination of unit and quantity. New types of quantities can be created by multiplying and dividing existing base or derived quantities.

dim.Acceleration is a predefined instance of the dimension class provided by the library. Each class provides ready to use units, such as m, s and kg. There are also complex derived classes for units with special names, such as N for Newtons.

Usage of quantities follows along similar lines:

feature {NONE} -- Initialization
make (mass_1_: QUANTITY; mass_2_: QUANTITY) is
-- Load the machine
require
is_mass_1: mass_1_.commensurate_with (kg)
is_mass_2: mass_2_.commensurate_with (kg)
do
mass_1 := mass_1_
mass_2 := mass_2_
end

feature -- Access
mass_1: QUANTITY
mass_2: QUANTITY

acceleration_1: QUANTITY is
-- acceleration of mass 1
do
Result := (mass_2 - mass_1) / (mass_1 + mass_2) * Gravity
ensure
Result.commensurate_with (m * s^-2)
end

The library performs all semantic validation at run-time. The information needed for this is carried in the instances of quantities. There is no mechanism for checking the correctness of code at compile-time.

Excel

Although technically not programming languages, spreadsheets are similar to declarative functional languages with reactive semantics. They are used as a tool in many financial, engineering and scientifc applications, and therefore the automatic detection of unit errors can be desirable.

XeLda

In Validating the Unit Correctness of Spreadsheet Programs (PDF) from 2004, Tudor Antoniu et. al. describe a standalone prototype tool for unit checking Excel spreadsheets. Users may annotate spreadsheet cells that contain either values or formulas with a (possibly empty) list of unit names and associated exponents.

For example, an annotation for a force value could be:

((kilogram 1) (meter 1) (second -2))

The names of units are arbitrary, and their order is not important. The tool parses the cells and annotations in a bottom-up fashion, generates and evaluates unit constraints, and then colors any cells with with consistency errors. It also provides a textual explanation.

Fortran

Fortran continues to be the predominant programming language of the physical sciences. Surprisingly though, the representation of physical units had not been addressed systematically until more recently.

PHYSUNITS

Grant Petty developed a software package (paper) that adds automated computation and consistency checking of physical dimensions and units to Fortran 90. The implementation has a run-time cost for computations and storage, because dimension information is carried alongside numerical values in additional memory and computed by overloaded operators.

The module implements a number of SI units, which are represented as constants, such as u_meter. The following is a valid program that declares velocity, mass and acceleration to compute various energies:

v = 10.0*u_meter/u_second
m = 5.0*u_kilogram
g = 9.807*u_meter/(u_second**2)

kinetic_energy = 0.5*m*v**2
potential_energy = m*g
total_energy = kinetic_energy + potential_energy

Fortress

The discontinued language Fortress, a DARPA funded research project started by Sun Microsystems and later slashed by Oracle, had syntax support for dimensional analysis. Of particular interest are the dim and unit keywords that are used to declare dimensions and units respectively.

The language has largely disappeared from the internet, and most of the original related publications are no longer available. Some up to date details can be found in the language specification and a chapter in the Encyclopedia of Parallel Computing.

The following code demonstrates the declaration of base and derived dimensions, base and derived units with and without scaling, as well as their use in program statements:

dim Length default meter                 (* base dimensions *)
dim Time default second
dim Velocity = Length/Time               (* derived dimension *)

unit meter m: Length                     (* base units *)
unit second s: Time
unit joule J: Energy = newton meter      (* derived unit without scaling *)
unit centimeter cm: Length = 10⁻² meter  (* derived unit with scaling *)

d: RR64 Length = 2 m_
t: RR64 Time = 4 s_
v:= d / t                                (* 0.5 m_/s_ *)

Frink

Another language with built-in support is Frink, although it is more of a tool for physics calculations than a general purpose programming language. Units of measure and unit conversion are a major pillar of the language’s design and largely driven by a data file consisting of predefined units, prefixes, constants and relationships.

The following code demonstrates the declaration and usage of variables:

mass = 2 kg
gravity = 9.81 m/s^2

force = mass * gravity  // 19.62 kg m/s^2
force2 = 19.62 newton   // same as 'force'

The author has put considerable effort into analyzing the pitfalls and ambiguities of representing physical dimensions in computer programs using standard mathematical notation and orthography. The language also has some other interesting features that make it worth a look.

F#

The first general purpose (and hitherto only mainstream) programming language with built-in support for static checking and inference of units of measure is F#. Andrew Kennedy’s blog has a brief overview (Part 2, Part 3) of that particular feature. You might also want to read his related paper and dissertation for some more theoretical background.

The language provides a Measure attribute that enables the declaration of measurement types, which can then be used to annotate numerical values using an angle bracket notation. Derived units are type aliases for algebraic combinations of base units. The language also supports unit conversions, dimensionless quantities and generic functions.

The following code declares base and derived unit types and demonstrates their semantic equivalency when used in program statements:

[<Measure>] type kg            // declaration of base unit types
[<Measure>] type m
[<Measure>] type s

let mass = 2.0<kg>
let gravity = 9.81<m/s^2>
let force = mass * gravity     // 19.62<kg m/s^2>

[<Measure>] type N = kg m/s^2  // declaration of derived unit type

let force2 = 19.62<N>          // same as 'force'

Haskell

Haskell’s strong static typing and widespread use in the scientific community make it a prime candidate for researching dimensional analysis in programming languages. A number of different solutions exist, and the most popular ones are presented below.

Boyer

Stephan Boyer presented a simple approach using function spaces. It has a few limitations, such as an awkward construct/destruct syntax and a need to arrange arguments of unit operations in the right order.

type Length = BaseQuantity Meter

tableWidth :: Length
tableWidth = construct 1.5

tableHeight :: Length
tableHeight = construct 2.5

tableArea :: Area
tableArea = tableWidth .*. tableHeight

dimensional

The dimensional package (Hackage) is a recent dimensional analysis implementation that has a slightly more familiar syntax based on Closed Type Families and Data Kinds for dimension tracking.

leg :: Length Double
leg = 1 *~ mile

speeds :: [Velocity Double]
speeds = [60, 50, 40, 30] *~~ (kilo meter / hour)

physics

The physics Haskell package is the oldest implementation of dimensional analysis in Haskell that I could find. It is fairly simple and limited.

test1 :: Velocity -> Time -> Length
test1 m n = mult m n

test2 :: Length -> Time -> Velocity
test2 m n = divide m n

units

The units package (Hackage) is a more sophisticated solution that provides a fully extensible embedded type system with support for independent notions of dimensions and unit, inter-convertible units of the same dimension, unit-polymorphic programs, and unit prefixes. It also includes definitions for SI units.

-- dimension definition
data LengthDim = LengthDim
instance Dimension LengthDim

-- derived dimension
type VelocityDim = LengthDim :/ TimeDim

-- unit definition
data Meter = Meter
instance Unit Meter where
type BaseUnit Meter = Canonical
type DimOfUnit Meter = LengthDim

-- value type definition
type Length = MkQu_DLN LengthDim LCSU Double

-- values and prefixes
len :: Length
len = 3 % Meter

longLen :: Length
longLen = 150 % kilo Meter

-- value computations
vel = (3 % Meter) |/| (2 % Second)

uom-plugin

A completely different implementation approach can be found in Adam Gundry’s uom-plugin package (Hackage). It uses GHC’s facility for type checker plug-ins to add support for units of measure. The [accompanying paper](http://adam.gundry.co