There are a lot of programs in scientific and engineering computing using lots of different implementations for the handling of physical units. Most of these implementations only deal with a small portion of the overall topic. Considered in detail, this topic is quite complex.

None of the developers consider the topic of physical units as central to their business, and in fact it isn't. Therefore the hope is that an open source development might help to improve the correctness and usability of the scientific software. The library is subject to the Boost Software License. This license is quite liberal, basically you may use (and modify) it in any of your projects (both commercial and open source) without the obligation to publish the rest of your code.

Customer Benefits


Barton & Nackman

Barton & Nackman (FXIME: reference) do not consider the physical units as central but the physical quantities as central topic. They propose a static, template-based implementation where the pyhsical unit is encoded in the type of the Variable. That way, the compatibility can be checked by the compiler. The key to this technique is that not only types but also integral constant expressions are allowed.

FXIME: example

Such a static approach is suitable for situations where you know at the time of writing the program what kind of physical quantities are considered. This however is less often the case than you might expect at first sight. Examples are any flexible backend-storage for intermedeate results, configurable user interfaces, inputs and outputs.

Furthermore no names and prefixes are supported.




SIunits (The SI Library of Unit-Based Computations)

reviewed and not accepted for boost


mailing list




Quan - PQS - reviewed and not accepted for boost


sourceforge - ??

General Thoughts


There is no one-to-one mapping of physical quantities and units:
Energy = 5 Newton * 1 meter

Torque = 5 Newton * 1 meter

These two quantities have completely different meanings that has to be furnished by the developer (in this case by the use of suitable variable names). It is impossible to decide automatically on the physical meaning of the expressione "5 Netwon * 1 meter" without further information.

Physical units define certain quantities that other quantities can be compared against (FIXME: ref NIST-website). Thus a unit identifies (only) the scale on which a given physical quantity can be measured on, not the kind of quantity itself. A given unit can preclude a certain set of possibilities but can never give a positive statement.


The are a lot of currencies that money can be measured in. However, these are not trivially convertible by some fixed constants like kilograms and metric tons. Indeed an amount of US dollars is a different quantity than a corresponding amount of Euros, since their relation may vary, i.e. depend of time location and other factors.

If you ever converted your paypal account several times back and forth between different currencies, you already know that such conversion should never be automatic but only done on explicit request.

Expandable Unit system

Additional quantities may be considered as physical, like katal (katalitic behaviour, suggested to the SI commitee), or a measurement of customer satisfaction that is expressed in terms of "subjective assessment" numbers, ranging from 1 (worst) to 10 (best). The system of compile-time checked quantities may be expanded in a header file or the switched to another physical quantity model (see Configuration options). The system of dynamic quantities could be configurable, but is currently not (yet).

Admissible Ranges, Relative Quantities, etc

There are several quantities that have certain restrictions on their numerical range. Concentrations may not be negative and may not exceed 100%; thermodynamic temperatures below 0 Kelvin don'*t make sense and so on. However negative values may be interpreted as difference between other admissible values. This difference does not really matter most of the time. For units with non-zero offsets however, things get more complex as the difference then has a zero origin.

Examples of units with non-zero origin are temperatures, measured most commonly in Celsius or Fahrenheit. Both of these have an arbitrary origin somewhere in the human-percievable range, but both far away from the origin of the thermodynamic temperature at 0 Kelvin. For the purpose of this library, such offsets are not allowed for template-based implementations of quantities but only for runtime-checked ones.

Handling of special cases

The handling of nontrivial conversions should be as clean as possible. It is yet unclear how this can be accomplished.

Avoid Performance overhead where possible

A template based implementation has the potential to run without any overhead with respect to plain numerical values. Depending on your compiler, your milage may vary. No performance tests were done up to now.

In those locations where you need the additional flexibility of a runtime checked implementation, you will in any case pay for it in terms of memory consumption and computational time. Investigations will be made to find a suitable compromise here.

Symbol management in the Code

A library of physical units will inevitably define many symbols, of which some might conflict with other symbols in your program. Defining those symbols in a separate namespace surely is a good thing but only half of the solution. Many programmers undermine this by simply importing all symbols from another namespace by "using namespace xyz". This can lead to conflicts; even later, e.g. by additionial predefined units.

Any library suffer from this, a library of physical units defines a large number of mostly short symbol names, so the potential of collisions is particularly high. Basically the issue is to balance comfort versus safety.

A good workable solution is to import only specific symbols by "using physical::unitsymbol_double::cm". Another viable approach is to define a short local alias name for the enclosing namespace by "namespace u=physical::unitsymbol_double" and noting u::cm afterwards. (see namespace physical::unitsymbol_double).

Error Detection

Language Dependencies

Formatting physical quantities

Need clear distinction between Arithmetik and presentation layer.

Input possibilities for the user

Rational Exponents

This library supports only integral exponents to the base units. Units with rational exponents mostly occur in some kind of parameter fitting approaches:

force = alpha * (velocity)^p

Here, alpha should have the unit of Newton*(s/m)^p. But what happens if we decide to express the velocity in any other unit? Due to the nonlinearity introduced by p, this mapping is in general not clear. To avoid that please reformulate the above to

force = beta * (velocity/(m/s))^p

The expression velocity/(m/s) (read: velocity expressed in meter per second) is then dimensionless, while beta has now the unit of Newton.

The overall expression is now independend of the unit the velocity is stated in and no rational exponents are necessary. That is why rational exponents are deliberately not supproted by this library.

Generated on Mon Apr 2 22:25:06 2007 for physical_svn by  doxygen 1.5.1-p1
hosted on SourceForge.net Logo