"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
On Aug 20, 2006, at 10:42 AM, Andy Little wrote:
"Janek Kozicki" <janek_listy@wp.pl> wrote in message news:20060819212430.739b0920@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