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

From: Steven Watanabe (steven_at_[hidden])
Date: 2007-03-28 16:10:40

AMDG

Noah Roberts <roberts.noah <at> gmail.com> writes:

> Steven Watanabe wrote:
> 
> > I may be wrong, but in order to avoid any excess loss
> > of precision you have to store a set of all the base
> > units and track the actual unit at runtime involving
> > a merge with every multiplyor divide.  This kind of
> > overhead is not always acceptable.
> 
> I don't understand what you are saying.

suppose that you store the actual value and the
conversion factor.

struct quantity {
    double conversion_factor;
    double value;
};

Now multiplying two quantities requires two
multiplications.  Alternately, you convert
to SI before doing the multiplication and
return a different type. Either way you
introduce extra operations thus reducing
the precision of the result.

The only way I can think of to enable runtime
units without losing precision is

struct base_unit {
    double conversion_factor;
};
struct unit_impl {
    typedef boost::rational exponent_t;
    //keep this sorted to allow merge
    std::vector<std::pair<base_unit*, exponent_t> > impl;
    double conversion_factor;
};
static std::set<unit_impl*> all_units;

typedef boost::shared_pointer<unit_impl> unit;

struct quantity {
    unit u;
    double value;
};

Now all unit multiplications add the exponents of identical
dimensions.  Every time you create a new unit you look it up
see whether an identical unit has already been created. If
so than you return a pointer to the existing unit.  This
is so that you can explicitly set the conversion factors
for complex units and thus get maybe another bit of precision.

> I've never seen that stated.  I don't believe it either.  If conversions 
> are not the point of the library than why is a very significant portion 
> of the library dealing with units and conversions?

A lot of code is dedicated to conversions because they are
rather difficult to implement given the current representation.
Most of it is in detail/conversion_impl.hpp which is highly
repetitious.  If I ever get around to simplifying it the portion
of the library dealing with it will appear much smaller.

In Christ,
Steven Watanabe