[boost] units review

From: Kevin Lynch (krlynch_at_[hidden])
Date: 2007-04-04 23:13:03

 >
 >    The review for the Quantitative Units library, submitted by Matthias
 > Schabel and Steven Watanabe begins today, March 26 and ends April 4.
 >

I apologize to the authors and other reviewers in advance for not
actively participating in the discussion over the review period, nor
in providing as detailed a review report as I feel this submission
deserves; project deadlines being what they are, however .... you know
the drill.

I'd also like to thank the authors for "diving into the breach" on
this one; there has been no end of discussion on dimensional analysis
and units over the last few years on the list.  Many proposals have
come and gone, with much heated discussion on their various merits.  I
commend them on their courage and fortitude in rising to the
challenge.

WHERE I'M COMING FROM
=====================

My background is in theoretical and experimental particle physics. I
have done extensive scientific simulation work, electronic data 
acquisition system design and implementation, software
control systems and data analysis.  I'm a "tight loop bit twiddler"
... one of the wackos that really needs zero-overhead, compile-time
dimensional and unit analysis, because I can't afford a performance
hit ... "reinterpret_cast is your friend, not your enemy". I would
find the ability to define non-standard unit systems invaluable (I'm
one of those "natural units for the problem" types ... CGS for E&M,
solar mass/AU system for astrophysics, "hbar=c=1" for particle
physics, etc).

While I understand the usefulness to others of runtime conversions,
they are not useful to my work.  Likewise, I don't need anything
beyond simple debugging output support, but again, I understand the
potential usefulness to others of configurable unit IO support.  To
me, layout compatibility with the underlying fundamental type is quite
useful.

This is all just to say that I think the library _as described in the
documentation_ is a good fit for my needs.  That said, I think the
library deserves to be reviewed in light of what it claims to be, not
what we might want it to be.  I do think it is reasonable to consider
whether the library is "flexible" enough to support extensions that
support those other needs.

MY REVIEW
=========

 > What is your evaluation of the design?

I really like the design.  I think it comes as close to the standard
domain notation as it is possible to get in compile time C++.  The
interface seems clean, and conversions between units and unit systems 
seem very nicely specified.  The issues with pow<R> and root<R> are
unfortunate, but that is a language shortcoming, not a library
shortcoming.

I'm not thrilled with the "quantity_cast" business, but my
understanding from earlier mailing list discussion is that this corner
of the library will see significant interface changes, so I won't
belabor this issue.

 > What is your evaluation of the implementation?

I fear that I have not given the implementation sufficient study to
make useful comments.  Although I note that my favorite CODATA
constant (Fermi's constant) is missing ... that itself is nearly
inexcusable :-)

I did play with Example 14 (performance measurements) a bit.  Fedora
6, g++ 4.1.1, Intel T7400.  Unoptimized, the quantity versions run an
order of magnitude more slowly than the double versions.  With any
optimization at all, there is no runtime difference, 2.6s, satisfying 
the zero overhead guarantee.

 > What is your evaluation of the documentation?

Overall, it's very well done.

I very much like the discussion of dimensional analysis ... it's
clear, concise, and with the right level of mathematical
sophistication.  It beats the pants off the discussion in the BIPM's
SI brochure, in substantially less space.

I would like to see a warning on example 4 ... the presented
"measurement error" type is insufficient for actual use in dealing
with measurement errors, since it doesn't deal properly in
correlations (quite a hard problem at compile time, I think):
assuming x is a measurement<double>, with x.e the error, a correct
error propagation would have
(2x).e == (x+x).e == 2(x.e)
whereas this class would get the addition wrong.  Additionally, it is
not well protected against internal overflow in the various arithmetic
operation.  But this isn't a review of "measurement<>", and it is
overall still a nice toy example of the relevant library functionality
and interface.

I'm not sure that example 7 or 8 bring much more to the docs (not that
there's really anything "wrong" with them, per se).  They aren't
"realistic", as they can't be used in production code, and no
solutions to their drawbacks are presented.  As toy examples, they are
fine, but by this point in the documentation, there are already a
number of excellent, clarifying toy examples.  Even further, example 9
DOES show how to solve the drawbacks of example 8.

Examples 14, 15 and 18 could use more discussion :-)  Particularly 
example 14, since the results seem to be highly dependent on the quality 
of compiler optimizations.

 > What is your evaluation of the potential usefulness of the libray?

I think it will be extremely useful to a broad group of users, 
particularly in scientific simulations.

 > Did you try to use the library?  With what compiler?  Did you have
 > any problems?

Regrettably, not beyond building and compiling some of the examples.  I
have not had the opportunity to write any code of my own.  But all of 
the examples compiled and ran as expected.

 > How much effort did you put into your evaluation? A glance? A quick
 > reading? In-depth study?

A few hours study of the documentation and examples, and following of
the discussion on the mailing list.  I have done more in depth study
of some of the alternative libraries (Walter Brown's SIunits and Andy
Little's pqs); while those are both good libraries, I would be more 
likely to actually use the current library because the interface and 
flexibility suit my tastes better.

 > Are you knowledgeable about the problem domain?

Yes.  I'm involved in experiments that do precision measurement, and a
good understanding of dimensional analysis, units, and the underlying
standards based approaches to their measurement and definition are
important to my work.

 > Do you think the library should be accepted as a Boost library?  Be
 > sure to say this explicitly so that your other comments don't obscure
 > your overall opinion.

I vote FOR acceptance.

And I got my vote in this time before the review period ended in my time 
zone :-)

-- 
-------------------------------------------------------------------------------
Kevin Lynch				voice:	[phone]
Physics Department			Fax: [phone]
Boston University			office:	 PRB-361
590 Commonwealth Ave.			e-mail:	 krlynch_at_[hidden]
Boston, MA 02215 USA			http://budoe.bu.edu/~krlynch
-------------------------------------------------------------------------------