[boost] Re: Units libraries... (long reply)

From: Deane Yang (deane_yang_at_[hidden])
Date: 2004-01-11 11:51:06

Andy Little wrote:
> up. These all arise because a physical quantity is Not a numeric.
> 
> with a numeric_type N_t one may find operator * declared like this:
> 
> N_t operator * (N_t, N_t);
> 
> However when using a physical_quantity type arg PQin_t the returned
> type PQout_t is Not(usually) the same as PQin_t:
> 
> PQout_t operator* (PQin_t, PQin_t);  // simple case :-)

Isn't the whole point of dimensional analysis to derive
the dimension and units of PQout_t from the two input factors?

And, normally, the two input factors have different factors.
Example:

You virtually never multiply time by time. But you do often
multiply speed by time to get distance.

I think there might be some confusion on what exactly dimensional 
analysis is, so let's review: Dimensional analysis defines what
arithmetic operations are allowed for dimensioned quantities.
Here is the complete description.

Allowed calculations involving just one dimension:
(A dimension is like a 1-dimensional vector space.)
You are allowed to do the following:
a) Add or subtract two quantities of the same dimension. (vector addition)
b) Multiply a quantity by a pure number (scalar multiplication)
c) Divide one quantity by another (find the scalar factor that
scales one quantity into the other)

(Note that multiplication of two quantities is NOT in this list.)

Allowed calculations involving more than one dimension:
(Tensor products and dualization)
a) If you multiply two dimensioned quantities, the result
is a quantity in the appropriate derived dimension (e.g., speed * time =
distance).
If one dimension is the reciprocal of the other, you get a pure number.
b) If you divide two different dimensioned quantities, the result
is a quantity in the appropriate derived dimension.
c) If you raise a quantity to a power (which is always a pure number),
you get a quantity in the appropriate derived dimension (e.g., distance
squared = area). (By the way, I have never seen any example involving
irrational powers. Rational powers, as many have observed, do occur
often enough.)

Allowed calculations involving an absolute dimension:
(An absolute dimension is a 1-dimensional affine space)
a) Associated to any absolute dimension (say, calendar date) is
a relative dimension (time difference).
b) You can take the difference between two absolute quantities
(two dates) and get a quantity in the corresponding relative dimension
(time difference).
c) You can add or subtract a relative quantity to an absolute quantity
(I prefer to call this a "shift", to distinguish it from
the addition of relative quantitites).
d) You are NEVER allowed to multiply an absolute quantity by any
other quantity or even a pure number. (ever want to multiply a
calendar date by a factor of 2 or by another date?)

The properties of relative dimensions form the fundamental principles of
dimensional analysis as created by the physicists. I have never
seen the properties of absolute dimensions elucidated as above,
but calendar time is a clearcut example. The boost date-time library
contains an effort to implement in that specific case the properties
described above.

I'll leave the discussion of "change of units" to another time.

But here is the cool part. The properties above do not apply only
to physical quantities but to virtually any quantity anyone would
ever need to measure or keep track of, whether it is money, time,
coupon periods, or pork bellies.

In fact, calendar time is outside the bounds of physics, as far as I know.

Some have decided that somehow dimensional analysis is a complicated
thing. It isn't, if you carefully strip away all the extraneous
information. It's
rooted in rigorous mathematical principles, so although man-made
conventions can create some confusion (calendar time being one of
the more egregious examples), they cannot undermine the
fundamental principles.

My understanding is that all of the proposed libraries implement
at least the properties of relative dimensions.

How should the library be structured? I would argue that there should
be a core library that implements "pure" dimensional analysis, as
described above. Then all the man-made conventions (SI units, calendar
time, currency) should be implemented as clients of the core library.

If I am not mistaken, Matthias Schabel has already done exactly this.
So right now my vote definitely leans towards his library (but I do
want to see the compile-time issues addressed).

> Now try to make That work with std::complex. :-) (note: Non integer
> powers-of-dimension will not help here )

Complex quanitities are for me clearly beyond the scope of
the current unit libraries. Higher dimensional analysis
is probably useful, but a lot trickier to implement.
1-dimensional analysis serves 90% of the needs.