Re: [boost] Boost Units library preview

From: Andy Little (andy_at_[hidden])
Date: 2006-08-20 10:19:59

"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. The fastest way ( at least 
from
my own admittedly limited experiments) to do this seems to be:

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

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..

<...>

>> 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.

regards
Andy Little