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/