[boost] [Review] Quantitative units - compile time vs runtime

From: John Phillips (phillips_at_[hidden])
Date: 2007-03-26 09:59:03

   I'll get the ball rolling on the question of whether building a 
compile time only library is a good choice. My current thinking is yes, 
it is. I have three basic reasons for this, so I'll list them all below.

   If the library is going to include a runtime component, it would be 
for unit conversions on the fly. Various implementation details for this 
have been discussed in the past, but they always boil down to choosing 
some annointed set of units that the program will really use, and 
converting anything that is not in those units to the preferred system 
(usually during I/O). If answers for users are desired in something 
other than the preferred system, this conversion is done after the 
calculations are finished.

   The goal of this approach is to provide automatic unit conversion, 
and thereby simplify code, while minimizing the impact on program 
performance. In some settings I think this is a very usable answer to 
the problem. However, for my work in specific I do not think it is a 
good choice.

   My first problem is with code simplification. In theoretic physics 
(which is my background), unit systems are chosen based on the problem 
at hand. The goal is always to simplify the notation and to make 
reasoning about the problem more natural. If this is done successfully, 
expressing the resulting equations in code is cleaner and more obvious. 
For example, the units chosen for many electro-dynamic calculations lead 
to equations that have no constant multipliers. Lack of these 
multipliers means no magic numbers hiding in the code, so no way to get 
confused by said magic numbers. In the part of the code that is the 
actual calculation, this leads to simplicity and easier debugging, as 
well as eliminating a few multiplications or divisions.

   My second problem is with numerical accuracy and stability. The 
distribution of floating point representable numbers inside the set of 
the reals is not uniform. Nor is the relative error due to round off 
uniformly distributed. In most cases, the relative error is minimized 
close to 1.0. (See references such as Accuracy and Stability of 
Numerical Algorithms by Nicholas Higham for details.) Thus, it is almost 
always advisable to use units where the quantities in the code are in 
the range around 1.0 in numerical calculations. There is no silver 
bullet for numerical stability any more than there is for any other 
coding issue, but this is sually good advice. In some cases, a wise 
choice of units can even make a problem cease to use floating point 
arithmetic and become a purely integer arithmetic problem (An example 
would be monte carlo simulation of spontaneous magnetization using the 
Ising model. More generally, it happens in situations where the discrete 
nature of quantum states is important.). Obviously, since integer 
arithmetic is exact, this eliminates all concerns with round off issues.

   The third problem I see is one of efficiency. In a well chosen unit 
system there are very few multiplicative constants in the equations that 
describe the evolution and state of the system. (Systems that manage to 
have few or no constants and where the measurements of interest are of 
order 1.0 are sometimes called natural units for the problem.) In the 
primary calculation of a tight loop, every multiplication or division I 
can avoid is important. If all calculations actually happen in some 
pre-determined, but not natural for my problem set of units these 
multiplications and divisions cannot be avoided, and in some cases 
become the dominant part of the calculation's use of resources. For 
simulation work where doubling the operation count on the main loop can 
be the difference between a project that can be done and one that can't, 
this is unacceptable.

   This is my opinion, and the reasons for it. In my work I would not be 
able to use a system that imposes conversions. Nor would I suggest such 
a system to my students.

   I think a system with conversions might be built on top of the 
library Matthias and Steven have provided (though I'm not sure, since I 
haven't tried), but one with conversions would be very hard to use as a 
platform for those of us who need to not have conversions. Thus I think 
the chosen design is a good one.

                        John