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