
Boost : 
From: Andy Little (andy_at_[hidden])
Date: 20060820 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk