Re: [boost] [Review][PQS] Review deadline

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2006-06-07 09:01:19

Gerhard Wesp wrote:
> Still, I'd like to make one suggestion.
> 
> I think that handling of dimensional quantities and conversion factors
> are orthogonal concepts and should be separated.
> 
> I suggest that for maximum transparency the library should *exclusively*
> handle quantities expressed in SI units.

This would be a BAD thing!

> I'm aware that this "mildly forces" developers to adopt SI units.  I
> consider this a Good Thing.

Err... see below.

> Conversion factors between non-SI units and SI units should be constant
> dimensional quantities, e.g. (assuming constructors from double):
> 
> const length foot                 =    .3048 ;  // Meter
> const power  european_horse_power = 735.4987 ;  // Watt
> const mass   pound                = 0.4535924;  // Kilogram
> // ...
> 
> This way, one could e.g. construct dimensional quantities like this:
> const power deux_chevaux = 2 * european_horse_power;

However, if you are working in *pounds*, and you want the *result*
in pounds (e.g. how many pounds of flour do I need to order?) then
you are going to end up with the result in kg!!

Also, in Britain we are still using miles per hour (despite having converted
to metric a long time ago!). Therefore, it would be silly to answer the
question "how fast do I need to travel to get to work in 10 minutes?"

And it is silly to use a calculation to determine what horse power car you
want to buy in Europe when the calculation says you need a car that
supplies 735 watts of power! ("Excuse me, do you have any cars that
have a power output of 735 watts?" -- at which point the sales person
will look at you blankly!)

It's not just silly things like that. If you are computing with really large
numbers (e.g. light years) or really small numbers (e.g. on the Planck's
constant level), do you really want them to be expressed in - and
calculated using - SI units, especially when this would lead to overflow
errors.

Can you answer this question using *only* SI units on current floating
point hardware: how long will it take to travel from here to the
Andromeda galaxy travelling at 0.2 light years?

And then you are forgetting physicists that need to measure electron
volts.

And the list goes on.

> Non-SI quantities would have to stay "out of the system" in normal
> floating point variables:
> 
> length altitude;
> double altitude_ft = altitude / foot;
> 
> Ignoring dimensionality, this is the notation Mathematica chooses.
> 
> I have done some engineering simulations, written a flight simulation
> framework and used one that uses US units (D6; see www.bihrle.com).  The
> D6 source code is riddled with magic constants.  I've collected some
> conversion constants in units.h of cpp-lib, see
> http://gwesp.tx0.org/software/.

If you are only working in electron volts, or light years, there is no
need for "magic" constants. These will only come into play when you
need to convert between units. Also, the examples you gave above
are plagued with magic constants because you cannot express 1ft
as 1.0!

BTW: this is not a rant against SI units. It is a rant about *only* supporting
SI units!

- Reece
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/