"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