[boost] Units, dimensions, physical quantities,...

From: Eric Ford (un5o6n902_at_[hidden])
Date: 2004-01-08 16:07:09

I recently cruised the boost archives and see there is once again some discussion about units, dimenisions, physical quantities, and so forth.  I don't have time for a detailed message, but I'll offer a few thoughts...

1.  It is important to distinguish between quantities with the same/different dimensions, quantities with the same/different units, and quantities with the same/different application (e.g. depth and length or pound of banana and pound of apples).  A good library should force users to use the appropriate dimensioned quantities.  I would prefer (but realize this is subject to other opinions) that such a library not force users to explicity indicate changes of units.  I beleive compile time checks of application might be nice sometimes, but not always.  So I would leave that up to the user.  To see one way to do this, check out my unit library in the archives that allows the user to make user of "unit tags"

2.  To represent physical quantities, some thing must be represented by the bit pattern normally used to store the number 1, whether it be a meter, mile, light year,...  Most of the time floating point arithmetic is good enough that the choice won't matter, but there may be some applications where it does.  Therefore, there needs to be some facility for changing the base units.  For those who have looked at libraries such as SIunits, you'll know that it can also be useful for the user to be able to change the base dimensions.

3.  On abbreviations...  Yes, there are times when using m for meters and s for seconds sounds great.  But such short names will inevitabily cause conflicts.  IMHO, adding underbads or such makes things confusing, inelegant, will scare away potential users, and may not even prevent all the possible conflicts.  Therefore, I beleive that full names should be used (e.g., length, meter, time, second).  For users who want to use shorter abbreviations, I would be happy to include a namespace which has those abbreviations.

4.  Perhaps, instead of trying to write a library, we should first write a specification, so that different people's unit libraries will have a similar interface.  Then someone can write (or modify an existing code) to be a reference implementation.  And then others can try to write librarys which meet the same specs, but have possibly better implementations.

Good luck,
Eric Ford

--------------------------------------
Protect yourself from spam, 
use http://sneakemail.com