[geometry][units] Vector Class
I imagine that using geometry/unit together will be common. I just posted these files on boost-user too, but I wanted the geometry/units developers to see what I've done. I think it was too difficult to make a Vector<quantity<U,T>> class. However, it could be done, so that is very good! The problem is that the geometry library assumes that the types of T*T and sqrt(T) is the same as T. terry
I imagine that using geometry/unit together will be common. I just posted these files on boost-user too, but I wanted the geometry/units developers to see what I've done. I think it was too difficult to make a Vector<quantity<U,T>> class. However, it could be done, so that is very good!
The problem is that the geometry library assumes that the types of T*T and sqrt(T) is the same as T.
This is a common problem (even for std::complex, though the spec disallows UDTs anyway...) - the accumulator and uBLAS libraries also have this problem because they do not correctly compute return types for UDTs. If the authors of any and/or all of those libraries (or some other interested parties) were interested in modifying them to fix this issue, it would probably make sense to refactor the boost/units/operators.hpp header into a more general segment of Boost to provide the operator_typeof_helper classes on a more general basis... Matthias
Hi Terry, Op 19-5-2010 14:29, Terry Golubiewski schreef:
I imagine that using geometry/unit together will be common. I just posted these files on boost-user too, but I wanted the geometry/units developers to see what I've done. I think it was too difficult to make a Vector<quantity<U,T>> class.
Agreed.
However, it could be done, so that is very good!
The bad news is: the cartesian_distance class will go away. One of the reasons is the one you showed in your attachment -- you actually have to reimplement the whole strategy including return type. The good news is that it will be simpler to implement, and actually the distance will have the same measure as the coordinate system, so meters -> coordinate system: meters -> distance: meters, no T*T vs sqrt(T) (or handled internally).
The problem is that the geometry library assumes that the types of T*T and sqrt(T) is the same as T.
Sure. During BoostCon I presented this "convertible to double" approach (which is cartesian_distance) and Eric remarked that it might give problems, using the return type in meta-programming, and indeed it does. Thanks for your efforts and sorry about the change needed in the near future, but I hope it will be simpler indeed. I'm still not sure about it anyway, the review report tells us to show how units can be integrated and I envisioned it being in the coordinate system, not in the point type. So I'll look more close into your implementation. Note also that a "vector" is actually not part of Boost.Geometry but we hope that it can live apart from it, e.g. as Emil's vector/matrix library, and work together (though there is currently some vector arithmetic present). Regards, Barend
Hello Barend, I decided to remove boost::geometry from the implementation of my Vector/Point classes and instead focus on how to tell boost::geometry how to use my classes. I've been using CGAL for a few years, so I'm "baby-duck" imprinted on that design. I also used CGAL for affine transforms and some spherical conversions, so I hope to try boost::geometry for that functionality as well. I really had a hard time understanding what a "geometry" was. I expected a "geometry" to be a "system", rather than an object. I also expected "points" to be referenced to a "reference frame" so that points that have difference reference frames cannot operate on one another without going through a transformation. Much as in std::chrono, time_points from different clocks cannot be operated on together. But durations, the difference of two time_points, are interoperable. CGAL was also very difficult for me to learn because they use the concept of a "kernel". Perhaps I'm not not geometry savvy, but I feel a need for a geometry library for dummies. It seems a shame to keep coding "point/vector" over and over. It reminds me of when I used to write linked-list-queues in C from scratch on every project... I really missed going to BoostCon this year. I hope you all had fun! Thanks for all the hard work! terry ----- Original Message ----- From: "barend" <barend@geodan.nl> Newsgroups: gmane.comp.lib.boost.devel To: <boost@lists.boost.org> Sent: Wednesday, May 19, 2010 3:40 PM Subject: Re: [geometry][units] Vector Class
Hi Terry,
Op 19-5-2010 14:29, Terry Golubiewski schreef:
I imagine that using geometry/unit together will be common. I just posted these files on boost-user too, but I wanted the geometry/units developers to see what I've done. I think it was too difficult to make a Vector<quantity<U,T>> class.
Agreed.
However, it could be done, so that is very good!
The bad news is: the cartesian_distance class will go away. One of the reasons is the one you showed in your attachment -- you actually have to reimplement the whole strategy including return type. The good news is that it will be simpler to implement, and actually the distance will have the same measure as the coordinate system, so meters -> coordinate system: meters -> distance: meters, no T*T vs sqrt(T) (or handled internally).
The problem is that the geometry library assumes that the types of T*T and sqrt(T) is the same as T.
Sure. During BoostCon I presented this "convertible to double" approach (which is cartesian_distance) and Eric remarked that it might give problems, using the return type in meta-programming, and indeed it does. Thanks for your efforts and sorry about the change needed in the near future, but I hope it will be simpler indeed. I'm still not sure about it anyway, the review report tells us to show how units can be integrated and I envisioned it being in the coordinate system, not in the point type. So I'll look more close into your implementation. Note also that a "vector" is actually not part of Boost.Geometry but we hope that it can live apart from it, e.g. as Emil's vector/matrix library, and work together (though there is currently some vector arithmetic present).
Regards, Barend
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Terry,
I decided to remove boost::geometry from the implementation of my Vector/Point classes and instead focus on how to tell boost::geometry how to use my classes. OK, I think in that way it will fit much better.
I've been using CGAL for a few years, so I'm "baby-duck" imprinted on that design. I also used CGAL for affine transforms and some spherical conversions, so I hope to try boost::geometry for that functionality as well. It does provide some transformations. I really had a hard time understanding what a "geometry" was. I expected a "geometry" to be a "system", rather than an object. A "geometry" does not exist in our library, besides being a namespace. We've several concepts, point, polygon, etc, and they are of course geometries, but we don't have the object geometry. All algorithms work (or should work) on any geometry.
I also expected "points" to be referenced to a "reference frame" so that points that have difference reference frames cannot operate on one another without going through a transformation. The "reference frame" is the coordinate system. You cannot calculate the distance between two points in different coordinate systems (unless it is implemented explicitly). For the arithmetic operations you are using, it is different indeed, those are a kind of lower level functions, which might be provided by a separate vector library in the future. But good point, currently you can add two vectors from different coordinate systems... We can solve that.
Much as in std::chrono, time_points from different clocks cannot be operated on together. But durations, the difference of two time_points, are interoperable. CGAL was also very difficult for me to learn because they use the concept of a "kernel".
Perhaps I'm not not geometry savvy, but I feel a need for a geometry library for dummies. It seems a shame to keep coding "point/vector" over and over. It reminds me of when I used to write linked-list-queues in C from scratch on every project... Boost.Geometry should be for both "dummies" and experts ;-). However, even in Boost.Geometry we didn't want to provide another matrix/vector
Boost.geometry doesn't have that kernel indeed. Precision is determined by the metafunction "coordinate_type", which can be float, double or high precision, as you experienced. library. So therefore: points, polygons, etc. The sample on the first page gives the dummy-case: point p1(1,2); point p2(3,4); std::cout << distance(p1,p2); it cannot be easier.
I really missed going to BoostCon this year. I hope you all had fun! Thanks for all the hard work!
You're welcome ;-) Sure it was great and hope you will be there next time! Regards, Barend
I finished a draft of a cartesian point/vector for dummies that works with boost::units. Here is an example usage of it. I should be able "tell" boost::geometry how to work with cartesian::point and cartesian::vector, right? Notice how you can't intermingle points from different reference frames (near the bottom of the example). I've attached the source code <snipped headers> using namespace std; using namespace boost; using namespace boost::units; using namespace cartesian; typedef quantity<si::length, point3d > Position; typedef quantity<si::length, vector3d > Displacement; typedef quantity<si::velocity, vector3d > Velocity; typedef quantity<si::time> Time; int main() { static const si::length m = si::meter; static const si::time s = si::second; Position p1 = point3d(1.0, 2.0, 3.0) * m; Position p2 = point3d(4.0, 5.0, 6.0) * m; Position p3 = point3d(3.0, 9.0, 4.0) * m; Displacement disp1(p2 - p1); cout << disp1 << endl; cout << abs(disp1) << endl; cout << abs_squared(disp1) << endl; p1 += disp1; cout << p1 << endl; Time dt(Time(0.1 * s)); Velocity v((p3 - p2) / dt); cout << v << endl; cartesian::vector<4, int> v_move = assign::list_of(3)(-2)(17)(33); cout << "v_move=" << v_move << endl; struct ECEF { }; point<4, int, ECEF> ecef_pt1 = assign::list_of(3)(2)(-10)(-13); point<4, int, ECEF> ecef_pt2 = ecef_pt1 + v_move; cout << ecef_pt1 << ' ' << ecef_pt2 << ' ' << (ecef_pt2 - ecef_pt1) << endl; struct Local { }; point<4, int, Local> local_pt1 = assign::list_of(19)(-18)(17)(-16); point<4, double, Local> local_pt2 = local_pt1 + v_move; cout << local_pt1 << ' ' << local_pt2 << ' ' << (local_pt2 - local_pt1) << endl; // cout << (local_pt1 - ecef_pt1) << endl; // won't compile // Compiles, but is senseless. cout << (local_pt1.from_origin() - ecef_pt1.from_origin()) << endl; return EXIT_SUCCESS; } // main ====== Output ========= <3 3 3> m 5.19615 m 27 m^2 (4 5 6) m <-10 40 -20> m s^-1 v_move=<3 -2 17 33> (3 2 -10 -13) (6 0 7 20) <3 -2 17 33> (19 -18 17 -16) (22 -20 34 17) <3 -2 17 33> <16 -20 27 -3>
----- Original Message ----- From: "Terry Golubiewski" <tjgolubi@netins.net> Newsgroups: gmane.comp.lib.boost.devel To: <boost@lists.boost.org> Sent: Thursday, May 20, 2010 10:36 AM Subject: Re: [geometry][units] Vector Class
I've attached the source code
Apparently, zipped attachments are not allowed. I'll try the .h and .cpp files independently... terry
On Thu, May 20, 2010 at 9:52 AM, Terry Golubiewski <tjgolubi@netins.net> wrote:
----- Original Message ----- From: "Terry Golubiewski" <tjgolubi@netins.net> Newsgroups: gmane.comp.lib.boost.devel To: <boost@lists.boost.org> Sent: Thursday, May 20, 2010 10:36 AM Subject: Re: [geometry][units] Vector Class
I've attached the source code
Apparently, zipped attachments are not allowed. I'll try the .h and .cpp files independently...
Zipped attachments are allowed just fine, I got your email with the zip of the files correctly.
participants (5)
-
barend -
Barend Gehrels
-
Matthias Schabel -
OvermindDL1 -
Terry Golubiewski