Boost logo

Boost Users :

Subject: Re: [Boost-users] [units] Automatic Physical Units in Mathematica and Boost.Units
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-01-03 15:01:47


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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net