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: (617) 353-6025 Physics Department Fax: (617) 353-9393 Boston University office: PRB-361 590 Commonwealth Ave. e-mail: krlynch@bu.edu Boston, MA 02215 USA http://budoe.bu.edu/~krlynch -------------------------------------------------------------------------------