On 1/5/11 9:55 PM, BCS wrote:
After a little more thinking I'm wondering if I'm targeting a
different use case than other people are thinking about.
The case I'm designing for, is where you have a relatively small
number of inputs (that may be in a mishmash of units and systems), a
relatively large number of computations and a relatively small number
of outputs. The systems that Andrei is arguing for may be more
desirable if there are relatively less computation (thus less
internal rounding) or if all or most of the inputs are in a
consistent system of units (resulting in very few necessary
conversions).
I'm primarily interested in the first use case because it is the kind
of problem I have dealt with the most (particularly the mishmash of
units bit) and for that, the two proposals are almost equivalent from
a perf and accuracy standpoint because each should convert the inputs
to a consistent system, do all the math in it, and then convert to
the output units (I'm not even assuming the outputs form a consistent
system). The only difference is that the current arrangement picks
the consistent system for you where the alternative allows (and
forces) you to select it.
I think this all is sensible. What I like about Boost units is that they
didn't define SI units; they defined a framework in which units can be
defined (and indeed "si" is a sub-namespace inside units that has no
special rights).
This review conclusion is a very good read:
http://lists.boost.org/boost-announce/2007/04/0126.php
I recommend to all to read the entire review thread to get an idea of
the scope and sophistication of the Boost review process. It has
tremendously increased the quality of Boost libraries. We need to get there.
Andrei
