Re: [boost] Boost Units library preview

From: Matthias Troyer (troyer_at_[hidden])
Date: 2006-08-20 15:55:47

On Aug 20, 2006, at 4:19 PM, Andy Little wrote:

>
> "Matthias Troyer" <troyer_at_[hidden]> wrote
>>
>> On Aug 20, 2006, at 10:42 AM, Andy Little wrote:
>>
>>>
>>> "Janek Kozicki" <janek_listy_at_[hidden]> wrote in message
>>> news:20060819212430.739b0920_at_absurd...
>>>> Andy Little said:     (by the date of Sat, 19 Aug 2006 13:03:42
>
> <...>
>
>>> double var1= 10;    // var1  meters
>>> double var2 = 10 ;    // var2 represents meters.
>>>
>>> var1 *= var2 ;        // var1 now represents an area in square  
>>> meters.
>>>
>>> Of course you cant do this  with a fixed_quantity:
>>>
>>> quan::length::m var1(10);
>>> quan::length::m var2(10);
>>> var1 *= var2 ;                         // Error
>>>
>>>
>>> I would guess that is an unacceptable restriction for many authors
>>> of algebra
>>> libraries.
>>
>> Why should this be an unacceptable restriction?
>
> If you want the highest performance then in place operations are  
> generally
> faster ( at least in my admittedly limited experience) than binary  
> operations,at
> least for UDT's.
>
>> All it says is that a
>> quantity with units is not a field, but that is obvious from the
>> start. I can multiply a vector (3m, 2m, 1m) by a factor of 5 but not
>> by a factor of 5m. I see no problem here at all, except if you assume
>> that the element type of a vector is the same type as the scalar
>> factor in your expression.
>
> It is also possible to multiply a vector quantity  by a scalar  
> quantity:
>
> #include <quan/three_d/vect.hpp>
> #include <quan/velocity.hpp>
> #include <quan/acceleration.hpp>
> #include <quan/time.hpp>
> #include <quan/mass.hpp>
> #include <quan/length.hpp>
>
> int main()
> {
>     typedef quan::acceleration::m_per_s2    accel;
>     typedef quan::velocity::m_per_s              velocity;
>     typedef quan::length::m                             length;
>
>     using quan::three_d::vect;
>
>     typedef vect<accel>     accel_vect;
>     typedef vect<velocity>  velocity_vect;
>     typedef vect<length>    distance_vect;
>
>     accel_vect      a(accel(1),accel(2),accel(3));
>     velocity_vect   u(velocity(0),velocity(-1), velocity(0));
>     quan::time::s   t(1);
>
>     distance_vect   s = u * t + 0.5 * a * quan::pow<2>(t);
>
> }
>
> The above creates a lot of temporaries of course.

Why? Using expression templates there will be absolutely no temporaries.

> The fastest way ( at least
> from
> my own admittedly limited experiments) to do this seems to be:
>
>    T s = u;
>     s *= t;

     s = t*u; seems faster to me since it is only one pass instead of  
two

>     T temp = 0.5;
>     temp *= a;
>     temp *= t;
>     temp *= t;
>     s += temp;

This is completely wrong. a is a vector and you thus cannot multiply  
it to the scalar 0.5

>
> In fact you can do in place addition of quantities of course, but not
> multiplication, or at least not without low level manipulations.
>
> It sounds like I am arguing against my own library. I'm not, but I  
> am pointing
> out that there are different considerations when using quantities  
> and you may
> not ( in fact probably wont)  get as good a performance as from  
> using inbuilt
> floats. Overall Quan is much more fun to use than floats though,  
> and I have
> enjoyed using it so far where possible..

In fact it seems to me that you are much better off using a nice  
linear algebra library that makes use of expression templates.

>
> <...>
>
>>> Maybe, if we can get Quan into Boost then we will be in a stronger
>>> position and
>>> there may then be interest in creating a linear generic algebra
>>> library for
>>> physical quantities, but I suspect that due to the above kind of
>>> issues, there
>>> will always be a great divide between a 'raw' linear algebra
>>> library and one
>>> that is designed to work with physical quantities.
>>
>>  I don't agree. For me there is no such thing as 'raw' linear
>> algebra. All linear algebra concepts work perfectly with quantities
>> with units.
>
> FWIW I do see the difference between using quantities and floats as  
> very
> coarsely equivalent to the difference between using an assembly  
> language and
> (say) C. When using quantities  you are effectively using  a higher  
> level
> language than standard C ++ using floats.

I disagree since the units part is optimized away at compile time and  
you should be left just with pure floating point operations at the  
end of the day.

Matthias