Re: [boost] Quantity library: any interest?

From: renej_at_[hidden]
Date: 2003-04-27 13:40:36

>>From: <renej_at_[hidden]>
>
>> >>From: <renej_at_[hidden]>
>> >
>> > There's another question. If we add angle as a dimension, then what
>> > kind of angle is it? There are several kinds of angles, such as
>> > radians (plane angle) and steradians (solid angle). If both were
>> > represented by the same angle dimension, then it probably wouldn't
>> > make much sense to add radians and steradians (and what would be the
>> > resulting quantity?), yet, the library would allow it.
>>
>> in our implementation (plane) angle is sufficient, so we don't bother
>> with solid angle for the moment. However, I think it should have it's
>> own dimension since steradian != radian^2 (although m^2/m^2 = (m/m)^2
>> ;-)
>>
>> but I think a unit library would reach a much broader audience if it
> allows
>> to choose what dimensions are handled and how. For my application
>> field it is necessary to incorporate everything related to robotics
>> (time, length, angle, charge, mass), but temp, luminious intensity,
>> amount of substance not really. I think it would be nice to be able to
>> select only those you need in a unit lib and add your own "dimensions"
>> if needed
>
> That would typically also make it more complicated to implement, than a
> library with a fixed set of dimensions, and fixed rules for their
> interaction.
>
> About a year ago, I experimented some with a very general SI unit
> library implementation, as part of the ACCU mentored-developers SI
> units project (http://homepage.ntlworld.com/mark.easterbrook/mentored/)
>  (hence my interested in this thread, besides general interest in
> science. :) ).
>
> At the time, I had quite recently read "Modern C++ Design", and thought
> about making a library where the units are stored in typelists. :) That
> would allow any number of units, and any units.
>
> The issue is defining the rules for operations on the units, though.
> Also, the following two units would be considered different (to use
> MPL, for illustration):
>
> mpl::list<kg<1>,m<1>,s<-2> > // kg * m / s^2 (newton)
> mpl::list<m<1>,kg<1>,s<-2> >
>
> simply because they are different types.
>
> I used derivation between the elements in the typelist, and Loki's
> DerivedToFront, to provide ordering, to make them equal. Then I had
> some hairy metaprogramming routines which took two typelists, and
> computed a new one, by adding or subtracting exponents of corresponding
> types in the two lists. Note that in this case, the two lists may
> contain different numbers and kinds of elements. Unless a policy is
> used to specify all dimensions for all units. The latter would mean
> that you have to rewrite all the unit definitions, if you add or change
> dimensions, though.
>
> The reason this was done - rather than the more simple approach of
> using a vector of integers (like the mentioned quantity<> template in
> my earlier posting), fixed in length, which may then be easily
> manipulated - was to provide flexibility with regard to the number and
> kinds of dimensions.
>
> However, I then realised that all this metaprogramming complexity would
> probably have quite a price, for more elaborate computations. It could
> increase the compilation time, for a flexibility that might not be
> used.

and that's what we face every day: huge compilation times because of
templates; so, minimizing this is indeed something to consider
OTOH, computers get faster and faster; for the moment they buy my
quote of Knuth that "premature optimization is the root of all evil"...

>
> Even with this flexibility, it still used the same rules for all units,
> so it still wouldn't cope with e.g. currency conversions, as it would
> happily multiply two USD's and give a USD^2. :)

true

>
> If you instead just use a vector of integers, you get all the SI
> dimensions, except that angle will be dimensionless. The question is
> whether it's worth complicating a library, and possibly increase the
> compilation time quite a bit, just to be able to treat something like
> angle as a separate dimension.

that's what we use now, except we added 'angle' as a dimension

>
> Even if angle is added as a dimension, to an implementation using an
> integer vector, it still wouldn't accommodate any other dimensions
> added later, without rewriting the library and unit definitions.

how about having the basic SI dimensions and a couple of extra
"to-be-defined-by-the-developer" dimensions. In that case, full
SI "compliance" and for those who want something extra they can have
it. I saw one of the discussed unit libraries provided something
like a dimension to be defined by the user/developer.

renej