Re: [boost] Boost Units library preview
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: Wednesday, August 16, 2006 7:46 AM To: boost@lists.boost.org Subject: Re: [boost] Boost Units library preview
Hi Eric,
...
Tested in VC7.1 and VC8.0 of vthe two examples gave compile errors. Testing in gcc 4.0 gave a failed assertion at runtime
I assume you mean the measure_test. Try the following simple patch: *** units-preview/libs/units/test/measure_test.cpp.orig Thu Aug 17 10:50:15 2006 --- units-preview/libs/units/test/measure_test.cpp Thu Aug 17 10:52:27 2006 *************** *** 38,52 **** feet f1 (1); assert (f1.value () == 1); f1 = 3; ! assert (f1.value () == 3); feet f2 (2); length_quantity q2 (f2); q2 = f1; feet f3 (q2); ! assert (f3.value () == 3); f2 = q2; ! assert (f2.value () == 3); // mixed units --- 38,52 ---- feet f1 (1); assert (f1.value () == 1); f1 = 3; ! assert (f1.value() > 2.999 && f1.value() < 3.001); feet f2 (2); length_quantity q2 (f2); q2 = f1; feet f3 (q2); ! assert (f1.value() > 2.999 && f1.value() < 3.001); f2 = q2; ! assert (f1.value() > 2.999 && f1.value() < 3.001); // mixed units Eric.
"Eric Lemings" <lemings@roguewave.com> wrote in message news:D730FF7CEDDCA64483F9E99D999A158B4203E5@qxvcexch01.ad.quovadx.com...
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little Sent: Wednesday, August 16, 2006 7:46 AM To: boost@lists.boost.org Subject: Re: [boost] Boost Units library preview
Hi Eric,
...
Tested in VC7.1 and VC8.0 of vthe two examples gave compile errors. Testing in gcc 4.0 gave a failed assertion at runtime
I assume you mean the measure_test. Try the following simple patch:
OK, but I don't see why it fails for Boost.Units but not for Quan: ---------------------------------------------- #include <quan/length.hpp> #include <boost/units/length_unit.hpp> #include <iostream> #include <cassert> int main() { std::cout.precision(32); // Quan quan::length::ft qft(3); std::cout << "quan qft.numeric_value() = "<< qft.numeric_value() << '\n'; assert(qft.numeric_value() ==3); // Boost.Units boost::units::feet f1(3); std::cout << "boost.units ft1.value() = " << f1.value() <<'\n'; assert (f1.value() == 3); } ----------- output: E:\projects\Test>testgcc quan qft.numeric_value() = 3 boost.units ft1.value() = 3 assertion "f1.value() == 3" failed: file "test.cpp", line 17 6 [sig] testgcc 3984 open_stackdumpfile: Dumping stack trace to testgcc.ex e.stackdump 33204 [sig] testgcc 3984 E:\projects\Test\testgcc.exe: *** fatal error - E:\pr ojects\Test\testgcc.exe: *** called with threadlist_ix -1 ------------------------------- ??? regards Andy Little
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
// Quan quan::length::ft qft(3); std::cout << "quan qft.numeric_value() = "<< qft.numeric_value() << '\n'; assert(qft.numeric_value() ==3);
Just a question: why is the member called numeric_value? are there other values? -Thorsten
"Thorsten Ottosen" <nesotto@cs.aau.dk> wrote in message news:loom.20060818T123417-474@post.gmane.org...
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
// Quan quan::length::ft qft(3); std::cout << "quan qft.numeric_value() = "<< qft.numeric_value() << '\n'; assert(qft.numeric_value() ==3);
Just a question: why is the member called numeric_value? are there other values?
The function is called numeric_value as it returns the numeric value of the quantity. quan::length::mi my_journey(25); // distance in miles quan::length_<int>::nm dx (25); // distance in nanometers The numeric value of journey is 25, the numeric value of dx is 25, but the units are very different. See for example (in http://physics.nist.gov/cuu/pdf/sp811.pdf) Page v, Checklist for reviewing manuscripts: item (7) "It is clear to which unit symbol a numerical value belongs ... etc" item (10) "There is a space between the numerical value and the unit .. etc" etc. regards Andy Little
Hi Andy, Andy Little wrote:
"Thorsten Ottosen" <nesotto@cs.aau.dk> wrote in message news:loom.20060818T123417-474@post.gmane.org...
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
// Quan quan::length::ft qft(3); std::cout << "quan qft.numeric_value() = "<< qft.numeric_value() << '\n'; assert(qft.numeric_value() ==3); Just a question: why is the member called numeric_value? are there other values?
The function is called numeric_value as it returns the numeric value of the quantity.
quan::length::mi my_journey(25); // distance in miles quan::length_<int>::nm dx (25); // distance in nanometers
The numeric value of journey is 25, the numeric value of dx is 25, but the units are very different.
What you are getting with the call to 'numeric_value' is the scalar component of the "quantity" - right? Just a suggestion then, would a more reasonable name for the method be 'magnitude'; it sounds better, and ties better to the problem domain. Cheers, -- Manfred Doudar - Research Engineer National ICT Australia - Canberra Research Lab | www.nicta.com.au Research School of Information Sciences and Engineering (RSISE) The Australian National University - Canberra, ACT 0200 AUSTRALIA
"Manfred Doudar" wrote
Hi Andy,
Hi Manfred,
Andy Little wrote:
"Thorsten Ottosen" <nesotto@cs.aau.dk> wrote in message news:loom.20060818T123417-474@post.gmane.org...
Andy Little <andy <at> servocomm.freeserve.co.uk> writes:
// Quan quan::length::ft qft(3); std::cout << "quan qft.numeric_value() = "<< qft.numeric_value() << '\n'; assert(qft.numeric_value() ==3); Just a question: why is the member called numeric_value? are there other values?
The function is called numeric_value as it returns the numeric value of the quantity.
quan::length::mi my_journey(25); // distance in miles quan::length_<int>::nm dx (25); // distance in nanometers
The numeric value of journey is 25, the numeric value of dx is 25, but the units are very different.
What you are getting with the call to 'numeric_value' is the scalar component of the "quantity" - right?
No I don't think so. When you get the numeric value of the quantity you have effectively lost some inportant information; IOW what the units are. It is necessary to be able to get at the numeric value, but as has been found in practise, once you do that then you have effectively exited the type checking and have to be very careful about what that number actually means.
Just a suggestion then, would a more reasonable name for the method be 'magnitude'; it sounds better, and ties better to the problem domain.
Again 'magnitude' would be more like ' value', where the 'value' of the quantity is numeric value + unit. magnitude IMO is a vaguely similar situation to 'numeric value' versus 'value', but in vector terms. When you get the magnitude of a vector you have lost the other useful information about the direction. In fact there is a 2D and 3d vector in quan so you can do: quan::some_vect< quan::length:: m > position_a, position_b; quan::length:: m distance_a_to_b = magnitude(position_b - position_a); Because of that useage It might get confusing. regards Andy Little
Andy Little said: (by the date of Sat, 19 Aug 2006 13:03:42 +0100)
In fact there is a 2D and 3d vector in quan so you can do:
quan::some_vect< quan::length:: m > position_a, position_b;
quan::length:: m distance_a_to_b = magnitude(position_b - position_a);
Because of that useage It might get confusing.
I still hold my position that linear algerbra library should not be a part of _two_ separate libraries: Dimensions and Units. Although Dave did not answer about details of his linear algebra library I agree with him that correctly written units+dimensions libraries should work with any other library - eg. small vectors (liear algebra), quaternions, octonions, matrices, etc... Specifically it should work with any other part of boost. If it wouldn't then the user of units library would be only limited to this linear algebra which is bundled with it. -- Janek Kozicki |
"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 +0100)
In fact there is a 2D and 3d vector in quan so you can do:
quan::some_vect< quan::length:: m > position_a, position_b;
quan::length:: m distance_a_to_b = magnitude(position_b - position_a);
Because of that useage It might get confusing.
I still hold my position that linear algerbra library should not be a part of _two_ separate libraries: Dimensions and Units.
FWIW I brought this up only in relation to magnitude. That said, I have found that being able to write code like the above is a lot of fun, much more so than if I was using doubles to represent lengths. However suddenly you are restricted in what you can do. For example: 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. As far as I am concerned though I am more interested to see what happens if I do play by the rules that are imposed by having strongly typed quantities, but it is kind of difficult to ask everyone to play by these rules, so I am happy to create vector types myself, that work with Quan. 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.
Although Dave did not answer about details of his linear algebra library I agree with him that correctly written units+dimensions libraries should work with any other library - eg. small vectors (liear algebra), quaternions, octonions, matrices, etc...
It is difficult to define 'correctly written'.... ;-)
Specifically it should work with any other part of boost.
If it wouldn't then the user of units library would be only limited to this linear algebra which is bundled with it.
From the work I have done so far it isnt that hard to make something that would work for other quantities libraries, and in fact the main problem is agreeing on a common result_type deduction scheme. Ideally one could use Boost.Typeof raw, but unfortunately gcc chokes on this type of declaration:
template <typename Lhs, typename Rhs> BOOST_TYPEOF_TPL(Lhs() * Rhs()) operator * ( Lhs lhs, Rhs rhs); Meanwhile, in practise it is not too difficult to write some glue code for interfacing with the other result_type deduction schemes such as Boost.Lambda and so on. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
template <typename Lhs, typename Rhs> BOOST_TYPEOF_TPL(Lhs() * Rhs()) operator * ( Lhs lhs, Rhs rhs);
Sorry that wasnt a very good example! template <typename Lhs, typename Rhs> vector<BOOST_TYPEOF_TPL(Lhs() * Rhs())> operator * (vector<Lhs>const &, vector<Rhs> const&); might be better. regards Andy Little
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 +0100)
In fact there is a 2D and 3d vector in quan so you can do:
quan::some_vect< quan::length:: m > position_a, position_b;
quan::length:: m distance_a_to_b = magnitude(position_b - position_a);
Because of that useage It might get confusing.
I still hold my position that linear algerbra library should not be a part of _two_ separate libraries: Dimensions and Units.
FWIW I brought this up only in relation to magnitude. That said, I have found that being able to write code like the above is a lot of fun, much more so than if I was using doubles to represent lengths. However suddenly you are restricted in what you can do. For example:
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? 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.
As far as I am concerned though I am more interested to see what happens if I do play by the rules that are imposed by having strongly typed quantities, but it is kind of difficult to ask everyone to play by these rules, so I am happy to create vector types myself, that work with Quan.
I don't see any reason why a correctly designed linera algebra library should not work with quantities with units
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. matthias
"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
On Aug 20, 2006, at 4:19 PM, Andy Little wrote:
"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.
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
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:B1F6950B-29D5-4F04-BDC0-7D6E7A56038F@itp.phys.ethz.ch...
On Aug 20, 2006, at 4:19 PM, Andy Little wrote:
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
OK. OTOH it prompted me to start writing another performance test. Its not finished yet, but in contrast to what I said it appears that Quan types perform quite well in comparison to inbuilts in this case ( based on two_param-branch in quan CVS which has had vectors improved relative to quan-0_1_0). As always one should be very careful with these tests!. In this case, maybe, because the Quan expression is evaluated first, it grabs the better registers. Anyway here is the source so far. I need to add some timing, but the assembly output from VC8 suggests that Quan does quite well in this particular case. It may mean I could write the double expression better too of course #include <quan/three_d/out/vect.hpp> #include <quan/out/velocity.hpp> #include <quan/out/acceleration.hpp> #include <quan/out/time.hpp> #include <quan/out/length.hpp> #include <quan/fixed_quantity/io/input.hpp> #include <fstream> /* vector of double v vector of quantities */ 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(333.),accel(444.),accel(555.)); velocity_vect u(velocity(666.),velocity(777.), velocity(888.)); quan::time::s t(.5); // nuke the optimiser { std::ofstream qos("quantity.txt"); qos << a.x << '\n' << a.y << '\n' << a.z <<'\n'; qos << u.x << '\n' << u.y << '\n' << u.z <<'\n'; qos << t <<'\n'; } { std::ifstream qis("quantity.txt"); qis >> a.x >> a.y >> a.z >> u.x >>u.y >> u.z >> t; } distance_vect s = u * t; distance_vect temp = a * t * t; temp *=0.5; s += temp; std::cout << "quantity vect result= " << s <<'\n'; // double version typedef vect<double> vectd; vectd a1(333.,444.,555.), u1(666.,777.,888.); double t1 = 0.5; // nuke the optimiser { std::ofstream os("double.txt"); os << a1.x << '\n' << a1.y << '\n' << a1.z <<'\n'; os << u1.x << '\n' << u1.y << '\n' << u1.z <<'\n'; os << t1 <<'\n'; } { std::ifstream is("double.txt"); is >> a1.x >> a1.y >> a1.z >> u1.x >>u1.y >> u1.z >> t1; } vectd s1 = u1; s1 *= t1; vectd temp1 = a1; temp1 *= 0.5; temp1 *= t1; temp1 *=t1; s1 += temp1; std::cout << "double vect result= " << s1 <<'\n'; } chopped output of respective calcs in VC* with a lot of optimsiation /////////////////////// quan calc ; 40 : distance_vect s = u * t; fld QWORD PTR _u$[esp+536] fld QWORD PTR _t$[esp+520] add esp, 4 fmul ST(1), ST(0) ; 41 : distance_vect temp = a * t * t; ; 42 : temp *=0.5; ; 43 : s += temp; ; 44 : ; 45 : std::cout << "quantity vect result= " << s <<'\n'; push OFFSET $SG-215 fld QWORD PTR _u$[esp+528] push OFFSET ?cout@std@@3V?$basic_ostream@DU?$char_traits@D@std@@@1@A ; std::cout fmul ST(0), ST(1) fld QWORD PTR _u$[esp+524] fmul ST(0), ST(2) fld QWORD PTR _a$[esp+540] fmul ST(0), ST(3) fld QWORD PTR _a$[esp+532] fmul ST(0), ST(4) fld QWORD PTR _a$[esp+524] fmul ST(0), ST(5) fxch ST(2) fmul ST(0), ST(5) fxch ST(1) fmul ST(0), ST(5) fxch ST(2) fmulp ST(5), ST(0) fld QWORD PTR __real@3fe0000000000000 fmul ST(5), ST(0) fmul ST(2), ST(0) fmulp ST(1), ST(0) fxch ST(2) faddp ST(4), ST(0) fxch ST(3) fstp QWORD PTR _s$[esp+524] fxch ST(2) faddp ST(1), ST(0) fstp QWORD PTR _s$[esp+532] faddp ST(1), ST(0) fstp QWORD PTR _s$[esp+540] call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@ // double calc ; 65 : vectd s1 = u1; fld QWORD PTR _u1$[esp+520] fst QWORD PTR _s1$[esp+520] add esp, 4 fld QWORD PTR _u1$[esp+524] ; 66 : s1 *= t1; ; 67 : vectd temp1 = a1; ; 68 : temp1 *= 0.5; ; 69 : temp1 *= t1; ; 70 : temp1 *=t1; ; 71 : s1 += temp1; ; 72 : ; 73 : std::cout << "double vect result= " << s1 <<'\n'; push OFFSET $SG-218 fld QWORD PTR _u1$[esp+536] push OFFSET ?cout@std@@3V?$basic_ostream@DU?$char_traits@D@std@@@1@A ; std::cout fld QWORD PTR _t1$[esp+524] fmul ST(3), ST(0) fmul ST(2), ST(0) fmul ST(1), ST(0) fld QWORD PTR _a1$[esp+524] fst QWORD PTR _temp1$[esp+524] fld QWORD PTR _a1$[esp+532] fld QWORD PTR _a1$[esp+540] fld QWORD PTR __real@3fe0000000000000 fmul ST(3), ST(0) fmul ST(2), ST(0) fmulp ST(1), ST(0) fxch ST(2) fmul ST(0), ST(3) fxch ST(1) fmul ST(0), ST(3) fxch ST(2) fmul ST(0), ST(3) fxch ST(1) fmul ST(0), ST(3) fxch ST(2) fmul ST(0), ST(3) fxch ST(1) fmulp ST(3), ST(0) fxch ST(1) faddp ST(5), ST(0) fxch ST(4) fstp QWORD PTR _s1$[esp+524] fxch ST(3) faddp ST(2), ST(0) fxch ST(1) fstp QWORD PTR _s1$[esp+532] faddp ST(1), ST(0) fstp QWORD PTR _s1$[esp+540] call ??$?6U?$char_traits@D@std@@@std@@YAAAV?$basic_ostream@DU?$char_traits@D@std@@@0@AAV10@PBD@Z ; std::operator<<<std::char_traits<char> > mov esi, eax ///////////////////////
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.
To be honest you have lost me here. Are you now saying it would be better for me to ditch Quan and start writing a linear algebra library for floats that uses E.T? There are a few of those around already. OTOH If an E.T library is any good then it should be possible to get Quan to work with it. However in the case of existing linear algebra libraries, they are all (including AFAICS MTL2) just set up for floats and possibly numeric UDT's.
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.
That is a different issue . Sure it is possible for the compiler to optimise the details of a higher level language and I am doing what I can to make sure it does so, but that doesnt change the fact that it's a higher level language. And as a user I have found Quan is a lot of fun to use. The issue is always going to be a lack of supporting libraries. For me though it is a good learning process to try to understand quaternions and more about linear algebra in general by trying to write some supporting librraies for quan. regards Andy Little
On Aug 21, 2006, at 7:20 AM, Andy Little wrote:
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.
To be honest you have lost me here. Are you now saying it would be better for me to ditch Quan and start writing a linear algebra library for floats that uses E.T?
No, I'm saying: don't worry about temporaries in your vector expressions but just use an expression template based library with your Quan types. There should be no problem. Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote <...>
The above creates a lot of temporaries of course.
Why? Using expression templates there will be absolutely no temporaries.
In my experiments with E.T, I found that it only became advantageous when use with (say) a vector of more than 4 elements. Before that it seemed to create more temporaries than eager evaluation. I seem to remember someone else backing this up somewhere too. The other problem with E.T. is that it affects the way you write expressions, as you sometimes need to force the evaluation: template <typename T> void f(T t) { std::complex<T> value(t,t); value * t; } double a,b ; f ( a * b); // OK f ( ET_expression(a , times, b)); // Error No operator * (std::complex<some_ET_expr> , <some_ET_expr>) IOW E.T. performance isnt free... regards Andy Little
On Aug 21, 2006, at 8:38 AM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
<...>
The above creates a lot of temporaries of course.
Why? Using expression templates there will be absolutely no temporaries.
In my experiments with E.T, I found that it only became advantageous when use with (say) a vector of more than 4 elements. Before that it seemed to create more temporaries than eager evaluation. I seem to remember someone else backing this up somewhere too.
That's strange since there should be no temporaries at all. The only thing to keep in mind is that in short loops over only 3 or 4 elements the time often gets dominated by the control structure of the loop and the inability to fill pipelines efficiently. Using small fixed-size data structures, such as the TinyVector in Blitz++ completely remedies that problem, and Dave's matrix library will take care of this as well. You still have not shown any reason why a special purpose matrix and vector library in Quan would be needed or useful. Matthias
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote in message news:E934060C-FDD6-40AC-A575-1B4907DBDF6D@itp.phys.ethz.ch...
On Aug 21, 2006, at 8:38 AM, Andy Little wrote:
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
<...>
The above creates a lot of temporaries of course.
Why? Using expression templates there will be absolutely no temporaries.
In my experiments with E.T, I found that it only became advantageous when use with (say) a vector of more than 4 elements. Before that it seemed to create more temporaries than eager evaluation. I seem to remember someone else backing this up somewhere too.
That's strange since there should be no temporaries at all. The only thing to keep in mind is that in short loops over only 3 or 4 elements the time often gets dominated by the control structure of the loop and the inability to fill pipelines efficiently. Using small fixed-size data structures, such as the TinyVector in Blitz++ completely remedies that problem, and Dave's matrix library will take care of this as well. You still have not shown any reason why a special purpose matrix and vector library in Quan would be needed or useful.
I suppose that at the end of the day, I am just interested in writing a very basic linear algebra library for Quan, especially to try to understand quaternions. regards Andy Little
On Aug 19, 2006, at 9:24 PM, Janek Kozicki wrote:
Andy Little said: (by the date of Sat, 19 Aug 2006 13:03:42 +0100)
In fact there is a 2D and 3d vector in quan so you can do:
quan::some_vect< quan::length:: m > position_a, position_b;
quan::length:: m distance_a_to_b = magnitude(position_b - position_a);
Because of that useage It might get confusing.
I still hold my position that linear algerbra library should not be a part of _two_ separate libraries: Dimensions and Units.
Although Dave did not answer about details of his linear algebra library I agree with him that correctly written units+dimensions libraries should work with any other library - eg. small vectors (liear algebra), quaternions, octonions, matrices, etc...
Specifically it should work with any other part of boost.
If it wouldn't then the user of units library would be only limited to this linear algebra which is bundled with it.
AFAIK any well designed quantity data type will work with MTL4 Matthias
Andy Little said: (by the date of Sun, 20 Aug 2006 18:52:32 +0100)
"Matthias Troyer" <troyer@itp.phys.ethz.ch> wrote
AFAIK any well designed quantity data type will work with MTL4
Where can I find information on MTL4 ?
looks like I have found it. Perhaps it took some time for google to index properly, because previously searching did not give any results: http://osl.iu.edu/research/mtl/ "In parallel, Peter Gottschling and Dave Abrahams started the development of MTL version 4.0." That sentence explains everything I was wondering about: - what is MTL4 - what is small vector library about which David was talking few months ago. It is great to see MTL revived, I had much hopes in the past about this library and was disappointed that it got abadonned. Now the future looks bright. However I'm still unable to find on the website wheteher MTL4 will support quaterion rotation (presumably in conjuction with Boost.Quaternion) -- Janek Kozicki |
On Tue, Aug 22, 2006 at 05:23:01PM +0200, Janek Kozicki wrote:
However I'm still unable to find on the website wheteher MTL4 will support quaterion rotation (presumably in conjuction with Boost.Quaternion)
Hey, that's easy to add as a free function, isn't it? Seems to me like the canonical solution if, like in this case, you're mixing data types from different libraries (i.e., presumably vector from MTL4 and quaternion from boost). Regards -Gerhard -- Gerhard Wesp ZRH office voice: +41 (0)44 668 1878 ZRH office fax: +41 (0)44 668 1818 For the rest I claim that raw pointers must be abolished.
Matthias Troyer said: (by the date of Sun, 20 Aug 2006 14:23:39 +0200)
AFAIK any well designed quantity data type will work with MTL4
can you elaborate what is MTL4 ? I remember there was once Matrix Template Library but it was abadoned in year 2002. Does MTL4 have quaterions, vector corssproduct, etc? -- Janek Kozicki |
participants (7)
-
Andy Little -
Eric Lemings -
Gerhard Wesp -
Janek Kozicki -
Manfred Doudar -
Matthias Troyer -
Thorsten Ottosen