Re: [boost] [Review] Quantitative Units library review begins today, March 26

From: Eric Lemings (lemings_at_[hidden])
Date: 2007-04-03 13:17:37

        What is your evaluation of the design?

My biggest design concerns at the moment:

1. The scope of the library must neccessarily be limited.  It should
contain the dimensional analysis framework, all predefined base and
derived physical dimensions, dimensionless constants, metric prefix
wrappers, possibly the SI units of measurement, and that's about it.
All other dimensions, units, and systems of measurement should be
treated as "localized" extensions that are built on top of this library.

2. Exponents should be tightly coupled to their respective dimension
or unit.  Specifying them implicitly in a list as a pair is not tightly
coupled.

        unit< meter, 1, gram, 2, second, -1 >

Make the exponent a template parameter of the dimension or unit.  This
syntax is more natural and more intuitive.

        unit< meter<1>, gram<2>, second<-1> >

3. Generally speaking, the vast majority of units are converted to one
another by simply multiplying the quanity by a factor.  The current
proposal potentially requires a separate template specicialization for
each of these conversions.  This type of conversion should be
generalized, if at all possible, into a single generic operation.

        What is your evaluation of the implementation?

My biggest concerns about the implementation:

4. Many Boost libraries follow the "fine-grained" header policy (e.g.
MPL) while also providing convenience headers that include entire
components or the entire library with a single include directive.
Looking at the proposed library, I would like to see at least one
convenience header file that includes the "core" library.  Also a few of
the headers are rather large and should be broken into smaller headers.

5. Don't see the need for ordinal class template.  How is it different
from the MPL integer constant wrappers?  There are also other such
questionable symbols (e.g. the whole operators.hpp header,
make_dimension_list).

6. Code that should ideally be included as part of other Boost libraries
(e.g. static_rational as part of Boost Math) should be defined within
the ideal namespace to indicate the intended namespace partitioning even
if the header currently resides in the proposed library.

7. The code sometimes confuses dimensions and units.  Example:

boost/units/systems/si/length.hpp:22:typedef
unit<length_type,SI::system> length;

Length is a dimension, not a unit.  The type name 'length_type' however
does have a sensible definition:

./boost/units/systems/physical_units.hpp:typedef
fundamental_dimension<length_tag>::type length_type;

Meter however is a unit and its dimension is length but to define
'meter'
as a constant, even a constant whose type is 'length', looks really
suspect of a design tradeoff:

./boost/units/systems/si/length.hpp:BOOST_UNITS_STATIC_CONSTANT(meter,le
ngth);  

Not sure about the benifits and drawbacks of such a design.

        What is your evaluation of the documentation?

Adequate for purposes of the proposal.  It would need quite a bit more
work to bring it up to the level of other Boost libraries.  Compared
to design and implementation of such a library, this is a relatively
small issue.

        What is your evaluation of the potential usefulness of the
library?

Apart from some usage issues and prototypical implementation, it's
headed in the right direction.  Some scientists and engineers will
certainly find it useful as is but many programmers will have issues
with its current form I believe.

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

I tried to build the examples on MSVC 8.0 and Mac OS X but couldn't
because there is only a BoostBuild v2 Jamfile and v2 is troublesome
to say the least.  A v1 Jamfile would have been extremely helpful.

        How much effort did you put into your evaluation?

Few days of code and documentation review with light experimentation and
testing of the examples.

        Are you knowledgeable about the problem domain? 

Enough to design and write a similar library and thus be aware of all
the issues involved with such development.

        Do you think the library should be accepted as a Boost library?

Not in its current form.  While it does demonstrate the potential for
becoming a Boost library, it needs more work.  Symptomatically, the
authors have stated that the library is still in development and I am
hesitant to formally accept any library that is still in development.
I would politely recommend that the authors gather, analyze, and
integrate all review commments so far.  I would also encourage rigorous
testing by a larger, more objective audience.

Eric.