Re: [boost] [Boost-users] [units] Automatic Physical Units in Mathematica and Boost.Units

Subject: Re: [boost] [Boost-users] [units] Automatic Physical Units in Mathematica and Boost.Units
From: Matthias Schabel (boost_at_[hidden])
Date: 2010-12-23 23:13:16

Alfredo,

As one-half of the Boost.Units developer's community (actually I should
also give due credit to Torsten Mähne for contributing the lambda component), 
I'll try to answer your questions :

> Does any body have experience with using boost.units quantity with a
> underlying type that are not double, e.g. multiple precision, or
> vector (geometric) objects? Does it work well?

For "well-behaved" types, Boost.Units should work transparently. See the examples
for complex and measurement types. I believe there are some users who have 
applied Boost.Units to vectors in varying coordinate systems as well.

> Are there future planned developments for Boost.Units, in terms of
> external features (e.g. automatic conversion, better interaction with
> boost.phoenix) or internal implementation?

Automatic conversion is a much-requested and highly contentious issue that
we intentionally did not support in the library, making the decision after much
careful consideration. It is difficult to do it correctly - in the situation where you 
have, e.g., mixed meters and feet :

1.5*meters + 3.7*feet

either there must be a specified default set of units to which everything is converted
or an arbitrary decision must be made by the compiler. While it probably doesn't 
matter too much in this case, and for MP numeric types it shouldn't matter at all 
(excepting execution time), there are possible unit combinations where truncation/
round-off could become a problem. There is no obvious way to determine this at 
compile-time. Why not just explicitly specify your default units of choice in your code - 
this is self-documenting and should be consistent and correct. Do you have a use 
case where the requirement of explicit unit specification is excessively problematic?

As far as Boost.Phoenix, what are the concerns? While I can't speak for Steven, I 
personally do not have a tremendous amount of time or resources to devote to 
Boost.Units on an ongoing basis; my bread-and-butter work is in medical imaging 
and, therefore, Boost.Units is a somewhat tangential project. That being said, one
of the beauties of the open source model is that other interested parties (you, perhaps)
are welcome to extend the work. Going from code that works for your particular 
application to code that is Boost-ready is non-trivial, but there are quite a number
of people who can help provide advice. Boost.Units.Phoenix would be, I'm sure, a
great addition to the library. 

As far as internal implementation, what are the concerns? 

Best,

Matthias