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

From: Martin Schulz (Martin.Schulz_at_[hidden])
Date: 2007-03-28 14:07:37

Matthias,

I'll split my answer in two parts. The more technical will follow.

> A Boost library isn't mandated to completely solve all 
> aspects of a given problem domain for all potential users. 

Maybe the whole conflict is only due to fundamentally different
expectations. When I read the introduction, full of words like "zero
runtime overhead", "in a general and extensible manner", "generic",
"arbitrary unitsystem models", "arbitrary value types", "general
facility", "fine-grained control", "complete SI and CGS systems" etc
then I (and I suppose others as well) get the impression that this
library certainly is the definite unit library that claims to solve any
unit conversion problem under the sun. 

Generally speaking, Boost libraries have a very high reputation to
actually solve the problem they claim to solve. 

But this one does not live up to my personal expectations raised by that
introduction. This is clear to me, but I am afraid others may take some
time to discover that fact the hard way. Maybe the not the library, but
just the expectation is wrong. To avoid such misconception, please give
your potential users the chance to adjust their expectations beforehand.

I'd suggest to add to the documentation a section like the following
(not exhaustive, you will probably add other points that are important
to you), clearly stating what can and what cannot be expected:

"Domain of application and restrictions

This library enables to specify the exact physical dimension of any
scalar or fixed aggregate quantity by encoding the dimension in the
respective type. 

The type system is able to deduce the internal type of a physical
quantity from arithmetic expressions involving other quantities fixed at
compile time. For storage in variables however, the user of the library
will need to specify the exact type. 

It is believed that the library is most useful when this type system is
applied to the whole program.

Since the library does not allow for mixed storage of quantities e.g. in
vectors, further workarounds will be necessary when dealing linear
algebra like BLAS, LAPACK or other advanced numerical libraries.

Because the physical dimensions of all quantities are fixed ad compile
time, there is no support for code that acts on certain quantities
regardless of what these quantities actually represent, i.e. all
quantities specified at runtime of the software. This includes GUI
frameworks, post processing or visualization tools.

The library provides support for language-independent serialization by
the use of Boost.serialization library. No attempt is made to ensure
that the units of the deserialized quantities match the ones of the
serialized ones.

No attempt is made to provide formatting for quantities in human
readable form (beyond debugging output).

No attempt is made to provide parsing of unit input in human readable
form."

Does this reflect the the admissible expectations more closely?

Yours,
        Martin.