Dimensional Arithmetics (Units of Measure) in Ada

Abstract

Types in Ada with their inherent strong binding lead, if applied correctly, to great data safety, i.e. they prevent comparing inadvertently apples with pears. This conception has proven so successful that languages like C, which originally had only very limited typing at their disposal, implement similar ideas in their new standards. Now also physical dimensions have the property of being combinable only in a very special way, and every physicist is used to checking equations with respect to dimensional correctness. So it is tempting to impose this chore upon the compiler by representing dimensions as types. This, however, is not that easy as can be seen by observing that indeed meter plus meter results in meter, yet meter times meter results in meter squared, and Ada operators work type-preserving: For A, B of type T, the product A*B is also of type T.

There are many examples in literature showing how to implement units of measure correctly and safely with Ada types. They all use methods similar to the one presented here.

Do not do this. The considerations below will show that Ada is even absolutely unsuitable to handling dimension checking in assignments with reasonable expenditure.

Let physical dimensions be implemented by Ada types:

type Length is new Float;
type Time   is new Float;
type Speed  is new Float;

The predefined multiplication and division operators are of no use since they remain within the type, and what is more, use of types in this naive way is liable to lead to gross misinterpretations. For error estimation e.g., the relative error Delta := Delta_x/x (a pure number) has to be declared as a dimensioned variable

Delta, X, Delta_X: Length;

for

Delta := Delta_X/X;  -- dimension 1

to be compilable, an awful misleading of potential readers of this program! (It is similar nonsense to call transcendental functions like exp for dimensioned arguments.)

There exist two possibilities to represent the equation s = vt in Ada:

S := Length (V) * Length (T);

or

S := V * T;

the "*" operator in the latter case being defined as follows:

function "*" (Left: Speed; Right: Time) return Length;

Use of the first way marrs the assignment with type conversions, rendering it unreadable (at least for more complicated equations) and thus error prone, and makes the compiler lose the ability to type check the operation by comparing dimensions on the left and right hand sides, which is the very reason for introducing different types for different dimensions. So rather than gaining, we lose.

Use of the second way on the first glance seems OK. We utilize the usual style of physical equations and the compiler checks the dimension during compile time. So in order to avoid the problem mentioned in the first paragraph, we use private types for our dimensioned units:

generic

  type Number is digits <>;

package Dimension is

  type Unit is private;

  --       "="   Equality is predefined
  function "<"   (Left, Right: Unit) return Boolean;
  function "<="  (Left, Right: Unit) return Boolean;
  function ">"   (Left, Right: Unit) return Boolean;
  function ">="  (Left, Right: Unit) return Boolean;

  function "+"   (Right: Number) return Unit;
  function "-"   (Right: Number) return Unit;

  function "+"   (Right: Unit) return Unit;
  function "-"   (Right: Unit) return Unit;
  function "abs" (Right: Unit) return Unit;

  function "+"   (Left, Right: Unit) return Unit;
  function "-"   (Left, Right: Unit) return Unit;

  function "/"   (Left, Right: Unit) return Number;

  function "*"   (Left: Number; Right: Unit  ) return Unit;
  function "*"   (Left: Unit  ; Right: Number) return Unit;
  function "/"   (Left: Unit  ; Right: Number) return Unit;

  function Measure (X: Unit) return Number;

private

  type Unit is new Number;

  pragma Inline ("<", "<=", ">", ">=", "+", "-", "abs", "*", "/",
                 Measure);

end Dimension;

The unary adding operators are used as constructors, which seems natural enough. Note that there is no multiplication of two dimensioned units; their devision results in a pure number.

Now we define our types:

package Physical_Item is new Dimension (Float);

type Length is new Physical_Item.Unit;
type Time   is new Physical_Item.Unit;
type Speed  is new Physical_Item.Unit;

function "*" (Left: Speed ; Right: Time ) return Length;
function "/" (Left: Length; Right: Time ) return Speed;
function "/" (Left: Length; Right: Speed) return Time;

Until here, everything is OK. So as long as you stay within the limits of this simplistic model, you may well use this method.

But you have to admit: This is not real physics.

Expanding this simple system to areas, volumes, accelerations ... affords more types and hence more functions.

type Area is new Physical_Item.Unit;

function "*" (Left,       Right: Length) return Area;
function "/" (Left: Area; Right: Length) return Length;

-- and so on for the other types

Now think of vectorial algebra. Computing the modulus of an acceleration vector leads to the fourth time power in the denominator. We begin to suspect this will become unruly: Until which power in each dimension shall we go? And we are far from the end of the road: The full SI system has seven base dimensions: meter, kilogramm, second, ampere, kelvin, candela, mol.

Our attempt leads us to a plethora of overloaded functions. The number of function definitions afforded runs into the hundreds. (By the way: although dimensions of intermediate results depend on the order the operators are executed in expressions like nRT/p, there is no need to introduce parentheses because operators of the same precedence level are executed in textual order from left to right).

One could object that this definition has to be made only once and for all in a reusable package, and later-on the package can simply be withed and used without any need for the user to care about the package's complexity, but unfortunately the argument is not fully correct. Apart from the most probable compile time explosion, it takes into account only simple multiplication and division. Operations like exponentiation aⁿ and root extraction root (n, a) are not representable at all. So how could we use this method for the (mixed) electrostatic unit system, which for several reasons is far better suited to theoretical physics? One esu (electrostatic unit) is defined as g^1/2 cm^3/2 s^-1, and gauss evaluates to g^1/2 cm^-1/2 s^-1. Here type conversions have still to be used.

So we have to confess that our attempt to let the compiler check equations at compile time has miserably failed. The only proper way to deal with dimensions in full generality is either to handle them as attributes of the numeric values that are calculated and checked at run-time or to use preprocessors. Also for these methods, there are many examples to be found in literature.

The preprocessor method can be left aside because constructing a preprocessor is normally too complicated.

The attribute method is unusable in cases where execution speed is essential.

So for hard real-time embedded systems, another way is needed to deal with dimensioned items. You can find such a method on my homepage under the title From the Big Bang to the Universe. It has successfully been in use for many years now in at least three avionic embedded systems. One Ada package, the Universe, is constructed that holds all basic definitions to allow dealing with physical quantities without type conversions while keeping the advantages of strong typing in critical cases. Basic mathematical functions like the square root and the sine are also included as predefined operations of the numeric base types, thus rendering possible the dimensionally correct computation of formulae like x=x₀cos(phi) in degrees and radians again without any type conversions.