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