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/
Reece Dunn wrote:
Gerhard Wesp wrote:
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?" Actually, it's worse than that. The UK began metricating in the 70s after decimalising its currency, but never actually finished the job. As a result, we are in a sort of limbo where both systems are in use. For example:
* petrol (gasoline) is dispensed in litres, a fairly recent change, but people still talk of miles to the gallon (rather than kilometres to the litre) * fruit and veg must be sold in kilos although may still be priced in pounds as long as they are also priced in kilos; many market stallholders still sell them in pounds, which is technically illegal, and some have been prosecuted; * road signs still give distances in miles and speeds in miles per hour, and there are no immediate plans to change this; * schoolchildren are taught the metric system but not the imperial (aka British) system, but most Britons still talk of inches, pounds, etc, so everyone ends up needing to know both systems and how to convert between them; * SI units are the only officially sanctioned units in scientific usage So including imperial (or even just non-metric) units is, I would say, quite important, not least because these are the official standard in the US. Just to complicate matters further, some units, for example the gallon, are different in the US and UK. Then of course there is avoirdupois and troy weight... Someone mentioned spelling variants: note there is also "liter/litre" as well as "meter/metre" (and their multiples and submultiples). Paul
On Wed, Jun 07, 2006 at 03:16:47PM +0100, Paul Giaccone wrote:
Reece Dunn wrote:
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!!
mass flour = x * pounds; // Do some computation std::cout << "You need " << flour / pounds << " pounds of flour\n"; Yes, if there is no other computation involved, we have an extra division and multiplication here. But as I wrote, I would like to encourage the users of a physical quantities library to actually use SI units.
So including imperial (or even just non-metric) units is, I would say, quite important, not least because these are the official standard in
I agree. But let them be themselves in SI, e.g. const length foot = .3048 ; const mass pound = .4535924; Regards -Gerhard -- Gerhard Wesp ZRH office voice: +41 (0)44 668 1878 ZRH office fax: +41 (0)44 200 1818 For the rest I claim that raw pointers must be abolished.
On Wed, Jun 07, 2006 at 08:42:14PM +0100, Andy Little wrote:
typedef double length; typedef double mass;
Well, of course I am speaking of types such that the expression mass x = foot/second; a compile-time error. IOW, for me a physical quantity would just be the bare template< int mass, int time, int distance, /* rest of 7 SI base units */ > class pq { double value; }; (add all the necessary construcors, accessors, operators, etc...; may also be templated on the value type.) I believe the rest of a PQ library can be created around this template. Regards -Gerhard -- Gerhard Wesp ZRH office voice: +41 (0)44 668 1878 ZRH office fax: +41 (0)44 200 1818 For the rest I claim that raw pointers must be abolished.
Gerhard Wesp <gwesp <at> google.com> writes:
IOW, for me a physical quantity would just be the bare template< int mass, int time, int distance, /* rest of 7 SI base units */ > class pq { double value; };
(add all the necessary construcors, accessors, operators, etc...; may also be templated on the value type.)
I believe the rest of a PQ library can be created around this template.
FWIW, this is exactly how I implemented the equivalent of "t2_quantity" in my own library. I find it to be what I need for most of my scientific computations. I look forward to its coming later (hopefully) in PQS. On the other hand, Andy implemented his "t1_quantity" first, and I see the value of that also, but for different situations. What you and I need is really the yet-to-come t2_quantity (and I need t3_quantity as well), but I think they can fit well into a common framework. What Andy has now is a good start, but t1_quantity alone doesn't satisfy all the users. I think that's the really source of some of the criticisms that PQS has received. -- Leland
participants (5)
-
Andy Little -
Gerhard Wesp -
Leland Brown -
Paul Giaccone -
Reece Dunn