Re: [boost] Interest in dimension/unit-checking library?

From: Andy Little (andy_at_[hidden])
Date: 2005-10-11 12:59:57

"Matt Calabrese"  wrote

> The example you gave is actually a barycentric combination with all weights
> equal. Just like in geometry, this does not mean that the addition operator
> should be defined for points to perform component-wise addition.
> Instead, I
> provide a "componentwise_add" function for such rare cases, and I will also
> be making a set of average and a barycentric combination functions to
> abstract away the concepts.

FWIW in pqs I worked very hard to make sure that operations worked smoothly
without "rare cases".  This approach made for ease of use with simple syntax.
The other area I worked hard at was dimensionless results for which I returned
the promoted value_type  of the operands. It would have been easy to provide a
dimensionless quantity but this too would fail in "rare cases".

>> Are there not subtleties with temporaries using ET that users need to know
>> about?
>
>
> I don't see a good reason to convert to the most fine-grained unit type. If
> anything, that can only cause more conversions which could not only make the
> expression less-optimized, but also have less-precise results depending on
> the value_type of the operands. I decided that determining the type to
> convert to be context is the best solution.

What would you output in a case such as :

    std::cout << millimeters(1) / seconds(1);

Have you thought about stream output ?

> Adding new classification types and new unit types is actually very simple
> at the moment. For derived classification types, it's as simple as:

[cut]

> Making new derived units is just as easy:
>
> typedef unit< miles, per< hour > > mph;
>
> // or
>
> typedef typeof( miles() / hour() ) miles_per_hour;

What do you do when two quantities have the same dimensional signature eg torque
and energy?

regards
Andy Little