Re: quantity libraries

From: Deane_Yang_at_[hidden]
Date: 2001-08-14 08:29:21

Disclaimer: I haven't had the time to examine the submitted 
libraries, so my comments might be completely irrelevant.

As I've mentioned before, I prefer to keep things very simple.
The other proposals I've seen appear to be much more 
ambitious.

I've found it useful just to define a separate class for each unit 
and a separate function for each conversion that I need.
My unit classes derive from a template base class that
defines common features (addition, subtraction, comparison, 
etc.). The "user" of this template can define any units and 
conversion he/she needs.

In other words, I follow the "don't please anyone" approach 
mentioned below.

So my code looks something like this:

Feet length_in_feet(12);

Meters 
    length_in_meters(UnitCast<Feet,Meters>(length_in_feet));

typedef Ratio<Meters,Seconds> MetersPerSec;
typedef Ratio<Meters,Hours> MetersPerHour;

// It would be better to use an overloaded operator/ here
MetersPerSec velocity(length_in_meters, Seconds(10));

MetersPerHour 
  new_velocity(UnitCast<MetersPerSec,MetersPerHour(velocity));

Seconds time(20);
Meters distance(velocity * time);

-------------end of code------------------------

The implementation just uses template specialization and is 
totally straightforward.

I don't try to implement commutativity and associativity
fully, so some formulas won't compile.  But that's easily fixed
either by rearranging the factors or inserting parentheses.

I'm more concerned about making sure that bad formulas do
NOT compile. I have found my classes very effective for that.
I've used it mainly in implementing financial valuation libraries
(bonds, options, swaps, etc.), where it is convenient to use
different units of time in different contexts.

--- In boost_at_y..., Anatoli Tubman <anatoli_at_p...> wrote:
> A quantity library that wishes to support both metric
> and English units must chose one of the following:
> 
> 1. All length are stored in meters.
> 2. All length are stored in feet.
> 3. All length are stored in units specified at configure time.
> 4. Some lengths are stored in feet, others in meters.
> 
> Every choice has its problems. Choices 1 and 2 are giving 
unfair
> preference to users of a particular unit system.
> Choice 3 gives unfair preference to users of *two* particular
> unit systems (unless you are willing to support every 
imaginable
> unit system at configure time). Choice 4, like 3, gives unfair
> preference to two particular unit systems -- but now to be fair
> you have to either support every imaginable unit system at *
run* time,
> or support support every imaginable *set* of unit systems at 
configure
> time.
> 
> We can see that it's hard to please everyone (surprise!). Given 
that,
> chosing an applicable international standard is one of more 
sensible
> decisions.
> 
> Another approach would be "don't please anyone". That is, 
provide
> *dimensionality* library and several independent *example* 
unit
> libraries (SI, English, Planck, whatever) on top of it. Users that 
want
> unsupported units can supply their own unit library. Hopefully, 
with
> ease.
> 
> Fortunately, it is really easy to refactor the proposed quantity 
library
> to support this last approach.
> 
> On Monday 13 August 2001 21:41, Thomas Matelich wrote:
> [snip]
> -- 
> anatoli at ptc dot com -- opinions are mine