Challenges for automatic UOME evaluators

Automatic evaluation of UOME unit expressions
UOME is designed to allow automatic evaluation of of nested unit expressions. At the same time, UOME is designed to make it easy for data providers to use and introduce units. This poses challenges for automatic UOME evaluators. In particular, an evaluator should be able to tolerate the following situations.


 * A unit may have a derivation, but not in terms of a given set of basic units.
 * A unit may have more than one derivation
 * Derivations may be redundant or circular
 * Relationships that should ideally be equivalent may differ due to floating point inaccuracies; these inaccuracies may add up as multiple steps are performed
 * Some expressions are equivalent to others: for example, a quotient is equivalent to a product with a factor to the power of minus one.

For example, watt can be derived from SI base units (i.e. kilogram, metre second), while a decibel may be derived as 0.1 bel, but not in terms of SI base units. An evaluator should be able to figure out that a watt is kilogram times square metre divided by second cubed, but should not get stuck on the decibel.

For example, kilogram may be derived as 1000 gram, and a gram may be derived as 0.001 kilogram. An evaluator should not be caught up in a loop trying to substitute kilogram and gram endlessly for each other.

For example, the unit watt per square metre is derived as watt divided by square metre. Watt is joule per second. Joule is kilogram metre squared divided by second squared. This means watt is kilogram metre squared per second cubed. And watt per square metre is kilogram per second cubed, so the square metre has cancelled. If an automatic parser tries to derive watt per square metre, the exponent of metre in the numerator may be slightly different from the exponent of metre in the denominator, but an evaluator should be able to cancel the square metre completely.

An evaluator should consider values identical if they are close enough to each other so that the difference could have been caused by floating point inaccuracies. Note that floating point inaccuracies may add up with every operation.

A simple evaluator could work like this: store a set of base units (e.g. SI base units), a list of derived units (initially empty) and a list of underived units (all other units). The goal is to evaluate each unit as a product of powers of base units times a number and plus some offset. Go through the list of underived units and whenever a unit has a derivation from one or two units that are all either base and derived units, evaluate it, remove it from the list of underived units and add it to the list of derived units. Repeat until a complete scan of the list of underived units yields no additional derived unit.