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