
Boost : 
From: Deane Yang (deane_yang_at_[hidden])
Date: 20031015 10:38:20
Beman Dawes wrote:
> In prior discussions of unitsofmeasure problems, it was pointed out
> that in many applications it might be necessary to tag types with more
> than just simple unitsofmeasure like gallons or liters.
>
> IIRC, prior discussions leaned toward solving such problems by allowing
> for user supplied unitsofmeasure. That would allow industry specific
> problems like the above examples to be solved without requiring the
> library to know about every unitofmeasure need in the world.
>
I would like to add my strong agreement to this. The utility of
a units/dimensions library goes far beyond physics, and it would
a less useful library if it is specifically tuned towards physics.
I would like to see a core library that does the following:
a) No predefined units of any kind
b) Allows addition and subtraction of same units
c) Automatic generation of new types when two different quantities
are multiplied or divided
d) Multiplication or division by a builtin allowed
e) No automatic conversion of units (of course, that's a given,
if there are no predefined units), but perhaps a clear framework
of how to implement automatic conversion when desired.
f) Allow rational powers of a basic unit.
g) The user does not have to hardwire in advance how many or what
units will be in the code.
(An aside for pure mathematicians only: this is basically implementing
the category of 1dimensional real vector spaces, and the dualization
and tenor product functors. Is it known to others that "units analysis"
could be described like this?)
It appears to me that both Hugo Duncan and David Abraham have described
how to do exactly this using mpl. There are, however, according to David
Abraham, issues of compiletime complexity that need to be addressed.
Having no experience in this yet, I can't comment on that, except to say
that in practice, I doubt that the typelist will ever be more than
three elements long and the exponent will take on more than about
10 different values between 3 and 3.
After that, a physics or SI units library could easily be built on
top of this. I think (but this might be wishful thinking) that building
the SI library on top of the core library will impose no serious
overhead on the SI library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk