[boost] Units libraries...

From: Dan W. (danw_at_[hidden])
Date: 2004-01-10 21:29:05

David Abrahams wrote:
 > On the other hand, premature generalization often spells design bloat
 > and death ;-)

I know, been there; --2 years wasted designing the classes for a 3D game 
engine, trying to cover every case, and no code.  Then, one day, I 
learned about XP, and in two months I had a basic engine working...

In this case, though, both tabled units libraries are already working; 
but making a few assumptions, some more than others, which, to correct 
them 5 years down the road would presumably break then existing code.

And some of the issues raised so far, it would seem to me, are fairly 
light in terms of the solutions needed:

De-coupling the type used for unit power:
Basically placing the operators code into a class, and referring to it 
via a template parameter.

De-coupling the value type:
Replacing occurrences of "double" with "V", then making V a template 
parameter.

De-coupling the library engine from any particular system:
Puttiog all system-specific stuff in a data file.

Full-name-ism vs. abbreviation-ism:
Providing an 'abbrv' namespace.

Compile-time:
Waiting for MPL::map<>.

Some of the issues are a bit more involved: The convenience of automatic 
conversions in some fields of application (e.g.: linear algebra) versus 
the need to have no automatic conversions when, say, both millimeters 
and inches need to be used, with accumulations, within the same code, 
for example.
One possible solution for this that's just crossed my mind would be to 
have the ability to set conversion targets:

set_target<mils>;  //mm get converted to mils
set_target<mm>;    //mils get converted to mm
set_target<mils,mm>; //converts meters to mm, feet to inches, but does 
not inter-convert between them except explicitly.

The old quagmire of radians, degrees and raw numbers: I thought at some 
point that this was a curious, but unique feature of dimensionless 
numbers;  until someone pointed out that Jouls are a measure of work, 
whereas Newton-Meters are a measure of torque, even though both are 
distance times force.  So the need for semantic distinctions among 
dimensionally equivalent units is not unique to raw numbers, but may 
happen anywhere. This needs more thought, IMHO.

The issue of whether there should be such thing as "length", apart from 
meters, inches and furlongs:  This is at the core of a units library. 
It needs to be settled.  IMHO, named dimensions should be optional 
decorations. Or perhaps they could serve an actual purpose, --e.g.: as 
per the previous paragraph.

Whether there should be a run-time absolute unit == 1, with all other 
units of the same dimension having run-time values != 1;  or whether 
each unit should be == 1 and the 'absolute' unit only exist at compile time.

The problem that some units don't seem to be made for add operations, 
such as date, position, temperature;  but which can only be added 
differential versions of themselves, such as days, distance, and 
temperature differential, respectively. Plus, many non-linear units: 
decibels, Richter, and UV-ratings.  Seems to me that some units will 
need custom and/or customizable operator overloads.

And possibly the hardest issue to deal with:  That in some models, such 
as used in particle physics, inverse-wavelengts equal energy equal mass; 
which is neither here nor there if we were to assume that systems are 
data files with a bunch of declarations, used in isolation;  but which 
could be a mess to deal with if such a system had to be used together 
with some other system, in the same program.

Last but not least, syntax.

The list of unresolved issues may seem long, but my experience with long 
lists of issues is that once the right solutions are found, they tend to 
cover most of the issues in one big swoop.

Cheers!