RE: [boost] Quantity library: any interest?

From: renej_at_[hidden]
Date: 2003-04-16 03:28:33

> There is DEFINITELY a need for this - and in the C++ Standard Library,
> but the relative merits of the two proposals mae so far are not yet
> clear to me.
>
> Perhaps we need more real user experience. (Or is the problem that the
> MSVC compiler can't/couldn't handle the SIUnits code?)

real user experience... you asked for it ;-)
we use the int-based template approach for a couple of years now in
our AGV controller software. We actually sometimes reach the stage that
it works when succesfully compiled and linked. Since our control software
is physics throughout (field of robotics), the type safety is very
important. However, besides the basic SI units we also have 'angle'
as a dimension which allows us to distinguish 'velocity' and 'angular
velocity' for example. Hence, from out 'real user' experience (engineering
point of view) it would be a necessity to add 'angle' as a dimension
without breaking already defined quantities. Most (all?) units libraries
already define 'angle' to be dimensionless, which is true in scientifically
spoken, but pragmatically (engineering ;-) less handy.

>
> I also feel strongly that users need to be able to handle 'uncertainty
> of quantity' by combining Quantity/SIUnits with the interval library
> (and something built on top of the interval library to include more
> information about 'uncertainty of uncertainty' clues like degrees of
> freedom). So I wonder if either or both fit together?

as an example, for the variables representing degrees of freedom of
the rigid body (AGV in our case), we have additional accuracy and
reliability variables. When those could make use of SI-based interval
valued variables, that would be indeed nice.

>
> Since Boost is not Standard, I think there will be room for both,
> especially after Pavel's note on the differences. So I am sure a
> submission will encourage testing, use, and documentation - especially
> persuasive examples.

looking at the several submitted packages and mentioned packages, I have
very good hopes that we can replace our home-brewed implementation by
the one in boost some day (soon?), but I'd like to stress that to
be usefull for a broader audience, one should be able to use it in parts
or layers: one part provides the necessary code and all the arithmetic
(without any specific types like 'length', 'mass', etc.), and other parts
provide the types for different models. Advantage of this is that it allows
users to take and combine only what the actually need. Real life example:
in robotics 'luminous intensity' and 'amount of substance' are not really
usefull (yet ;-), but 'angle' is.

for what it's worth,
renej