AMDG On 1/3/2011 11:06 AM, Matthias Schabel wrote:
For * and / I need it for a different reason, the library *can* multiply quantities from different systems but them it becomes very difficult to convert that quantity to a third system of units. It seems that explicit conversion can't handle such conversion even though all the conversion factors are defined. So by adding factors in an expression one can inadvertedly introduce many different systems of units that later can not be converted. AFAIK, if conversions are correctly defined there should not be a problem converting to a third system of units. Can you provide a small, self-contained example of the problem?
The problem is that the set of definitions required can get very weird when you mix base units with different dimensions.
I can share the code of these auto_conversion_operators if you are interested. Steven, any thoughts on implementing an expression-local way of allowing implicit conversions? It actually seems like it might be a great GSOC project to re-implement Boost.Units using Boost.Proto...
I suppose that it would be possible to use Proto when attempting to add/subtract different units with the same dimensions. We could allow constructs like static_cast<quantity<si::length> >(1.5*meters + 3.7*feet). The result of this is well-defined. Evaluating (arbitrarily complex) expressions of this form would actually be a fairly straightforward extension of the current conversion code. We'd just have to extract all the base units used in the expression, find a basis, and use that to form a common system to which everything can be converted. (I need to think about this more. I'm probably over-complicating it) In Christ, Steven Watanabe