[boost] Re: Eric Ford's Unit package

From: Hugo Duncan (hugoduncan_at_[hidden])
Date: 2003-03-06 10:22:50

On 6 Mar 2003 00:34:23 -0000, Eric Ford <azsro001_at_[hidden]> wrote:

>> This looks most interesting, and there most definitely remains a great 
>> need for a units handling package.

Definitely!

> - SIUnits includes some "advanced" features which introduce run-time
> cost, while my library does not include such features.  The main
> example is the ability within SIUnits to change at runtime that a
> dimensioned quantity should be displayed in terms of various units
> (introducing an automatically applied scale factor) and with various
> labels (used when printing).  While I "power user" could implement
> this within my framework (e.g., by specializing scale and label in
> mks_tag), I don't see much point.  If I want a time in years rather
> than seconds (default in mks), I can easily write cout <<
> time_till_graduation / year;

I have found in the past that there is a need to
distinguish between dimension handling and unit handling.

In the case of a physical calculation, I usually ensure that
the code works with a self consistent set of units, and thus
only need dimensionality, compile time, code.

Units then become important only in the user interface, and
I have a list of the units used in the physical calculation
for each dimension.

This is obviously only one way of using dimensions and units,
but I think an important one. The usual exception to the above
is for money where you are working with multiple currencies.

A couple of use cases, that I am unsure would be handled by the
current proposal:

I have a "Cost" class that records costs for different factories
in different countries.  The "unit" used for each is factory
is different, eg USD for factories in US, GBP for those in UK.
ie the unit varies per instance.

A similar situation occurs for "dimensions" of physical units.
eg. if you want a list of quantities used per output weight
or output pieces, then each item in the list has different
dimensions, eg. Watt seconds/time, Litre/piece, number/kg.
In this case I obviously have to give up the type checking,
but still need to be able to record a dimension, to allow
display in appropriate units.

> - My library allows for users to add qualifiers to dimensioned
> quantities which are strongly typed by default.  Users may choose weak
> typing (e.g., automatic conversion from mass of apples to mass of
> fruit or allowing a sum of mass of apples and mass of oranges to equal a
> mass of fruit) by relatively easy specializations.

Excellent!

Hugo