[boost] Physical quantities (was Re: runtime unit-modifiablephysical-quantitiesusingpqs1-00-01)

From: Deane Yang (deane_yang_at_[hidden])
Date: 2004-01-06 23:05:30

Dan W. wrote:
> I'm with ya.  The more I think about it, the more it seems to me that 
> the whole concept of "dimension" doesn't have one point of contact with 
> the problem domain.  All one needs is the units.  Of what, it doesn't 
> matter, really;  as long as we have ways to convert between units.
> 

Exactly! In my humble opinion the whole "physical dimension" thing turns 
out to be a journey down the wrong road. A physical dimension library
as proposed so far seems to me is useful only if

a) you always want quantities using a common
physical dimension to be allowed to be added together (so you want
to be able to add the mass of an apple and the mass of an orange).

b) you want to be able to mix different units for the same dimension
within a single line of code and allow the units to be set at runtime.

c) The only dimensions or units you want to use are one of the seven
physical dimensions. Moreover, you want to use, say, at least three
of them (if you use only one or two of them, the full seven-dimensional
library is overkill.)

Now don't get me wrong. I can definitely see situations where all of the 
above are exactly what you need. But in my humble opinion, there are 
many other equally if not more likely situations
(even for the physicists!), where you want:

a) programmer control over exactly what dimensions or units are defined
b) programmer control over what can be converted or not
(e.g., allow conversion from mass of apples and mass of oranges to mass 
of fruit, but do not allow any other conversions.)

In particular, I do not like defining dimensions such as length as types
and units such as meters as constants, because it begs the question of
how a dimension such as length should be represented internally (you end 
up choosing an internal unit to use). This point arose early in the 
discussion. I have always believed that the units should themselves be 
the types. To write "unit-free" code you simply use templates.
(The downside of this is that you lose the ability to choose units
at runtime. It is not clear to me how often this feature is really
needed, since you can always wrap the code with an interface that
accepts runtime-chosen units and converts them into a fixed set of
units used by the code.)

And if you want two different types that use the same units
but for different dimensions (mass of apples and mass of oranges), then
this is no problem at all for a library where the programmer (rather 
than the library author) defines the units.

And, wouldn't this units library be much simpler to develop than the
whole physical dimensions library? I think that Abrahams, Duncan, and
Schabel have already pretty much described how to do it. The only 
difficulty I am aware of is the compilation time involved in handling
lists of types that represent the different fundamental units in
a derived unit.

(At this point, I am in fact determined to write my own using MPL,
following the approach outlined by Hugo Duncan. It just sounds like
such a beautiful way to use C++, templates, and MPL. But given my other
responsibilities, this should take no more than five years to finish.
So don't hold your breath. I am haranguing the other proposers, hoping
that someone else will do the work for me.)