[geometry] Runtime dimensionality
Hello, I just started yesterday looking into boost.geometry to use on our own legacy system of Vertices (Points) in Meshes. I'm quite impressed how easy it is to adapt to existing code and got it working (with some workarounds) really quick. However, some problems remain. We have a Vertex object, with a dimension determined at runtime. The actual position is saved as VECTOR_T (usually an Eigen::VectorXd (double vector of arbitrary dimension)). One can get the coordinates using "const Eigen::VectorXd& Vertex::getNormal()" I was able to adapt to geometry by adding getters/setts for the dimensions: double getX() and getY() and BOOST_GEOMETRY_REGISTER_POINT_2D_GET_SET(mesh::Vertex, double, cs::cartesian, getX, getY, setX, setY) and it works! But in theory the vertices can be of arbitrary dimension, in practice it's usually 1, 2 or 3. What is the best way to adapt our Vertex object to geometry? - Change our Vertex so that it meets the model::point requirements. It worked so far, for the access I use: template<size_t Dimension> struct access<Vertex, Dimension> { static double get(Vertex const& p) { return p.getCoords()[Dimension]; } static void set(Vertex& p, double const& value) { Eigen::VectorXd vec = p.getCoords(); vec[Dimension] = value; p.setCoords(p); } }; In our code we rarely set the entries of an vector, so the code is a but ugly. Will likely change that to a compile-time get<Dim>() as a member of Vertex. My biggest problem is the dimensionality template<> struct dimension<Vertex> : boost::mpl::int_<2> {}; but I have no idea currently how to get that for an Eigen::VectorXd at compile-time? Do you have any idea? Thanks! Florian
On 26 September 2017 at 04:02, Florian Lindner via Boost-users <boost-users@lists.boost.org> wrote:
We have a Vertex object, with a dimension determined at runtime. T
This is not possible. Dimension is compile-time trait of any model in the Geometry, intrinsic or adapted. Unless my info is outdated. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot Via Boost-users wrote:
On 26 September 2017 at 04:02, Florian Lindner via Boost-users <boost-users@lists.boost.org> wrote:
We have a Vertex object, with a dimension determined at runtime. T This is not possible. Dimension is compile-time trait of any model in the Geometry, intrinsic or adapted. Unless my info is outdated.
Nothing've changed. Dimension has to be known at compile time. The way how this could be handled depends on the use case. What are you using Boost.Geometry for? Adam
This was presented at BoostCon I attended a number of years back. https://www.youtube.com/watch?v=RY_YSYz7b8I Pablo is a great guy to talk to about this. On Tue, Sep 26, 2017 at 12:19 PM, Adam Wulkiewicz via Boost-users < boost-users@lists.boost.org> wrote:
Mateusz Loskot Via Boost-users wrote:
On 26 September 2017 at 04:02, Florian Lindner via Boost-users<boost-users@lists.boost.org> <boost-users@lists.boost.org> wrote:
We have a Vertex object, with a dimension determined at runtime. T
This is not possible. Dimension is compile-time trait of any model in the Geometry, intrinsic or adapted. Unless my info is outdated.
Nothing've changed. Dimension has to be known at compile time.
The way how this could be handled depends on the use case. What are you using Boost.Geometry for?
Adam
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
The Maschine Via Boost-users wrote:
This was presented at BoostCon I attended a number of years back. https://www.youtube.com/watch?v=RY_YSYz7b8I Pablo is a great guy to talk to about this.
Thanks for the link, that's interesting but I don't have time right now to watch the whole talk. Let me be more specific. What's a set of Boost.Geometry operations that you'd like to use? E.g. would you like to do spatial indexing using the rtree, perform set operations, perform relational operations, etc? What's the maximum dimension? The most generic approach would be to set dimension to the highest dimension you support and then as Florian pointed out return 0 for dimensions higher than the actual dimension. Depending on the actuall use case the unneeded dimensions could be processed by the library anyway so this could harm the performance. But maybe it would be good enough for you. In some cases it would be possible to optimize the code, e.g. if you wanted to use the rtree you could pass your own equal_to getter checking only the important dimensions or overload e.g. boost::geometry::intersects() which is used by the rtree while performing boost::geometry::index::intersects() spatial query, etc. Regarding set and relational operations for polygons AFAIR only the first 2 dimensions are used in the most part of the algorithm anyway (besides actual points comparison I think). If the operation you'd like to perform was CPU-bounded, had the complexity worse or equal to linear, the max dimension was high but the actual dimension was low then it could be worth converting your geometry to e.g. one of the Boost.Geometry model having compile-time dimension. The conversion would have linear complexity so the overall complexity would stay the same and it could speed up the overall operation because you'd avoid processing the unnecessary dimensions. Converting the data could also increase performance if the fact that purely dynamic Eigen::VectorXd have data pointer to dynamically allocated memory caused cache misses while accessing data. This probably would be the case if the operation had complexity higher than linear because the conversion would be linear itself and I'm assuming that most of the time the program would wait for the data while copying or processing using linear algorithm. And so on... Adam
The Maschine via Boost-users wrote:
This was presented at BoostCon I attended a number of years back. https://www.youtube.com/watch?v=RY_YSYz7b8I Pablo is a great guy to talk to about this.
Thank you for this! So Versor is his work. Link: <http://versor.mat.ucsb.edu/> I have it, but have yet to play with it. I've really not done much since this <https://www.codeproject.com/Articles/9751/Part-One-Euclidian-Geometric-Algebra-and-Quaternio> I'm really going to have to get back into this stuff this winter. I'm just a fledgling aumetuer, but I love this stuff. Best, Dan, and thanks again....
Am 26.09.2017 um 14:40 schrieb Mateusz Loskot:
On 26 September 2017 at 04:02, Florian Lindner via Boost-users <boost-users@lists.boost.org> wrote:
We have a Vertex object, with a dimension determined at runtime. T
This is not possible. Dimension is compile-time trait of any model in the Geometry, intrinsic or adapted. Unless my info is outdated.
Ok, I expected that. Is there maybe a way to define the rtree's dimensionality upon creation? So that I can do: rtree<3, size_t, RTreeParameters, VertexIndexGetter>; 3 beging the dimension. Thanks, Florian
On 27 September 2017 at 03:57, Florian Lindner <mailinglists@xgm.de> wrote:
Am 26.09.2017 um 14:40 schrieb Mateusz Loskot:
On 26 September 2017 at 04:02, Florian Lindner via Boost-users <boost-users@lists.boost.org> wrote:
We have a Vertex object, with a dimension determined at runtime. T
This is not possible. Dimension is compile-time trait of any model in the Geometry, intrinsic or adapted. Unless my info is outdated.
Ok, I expected that. Is there maybe a way to define the rtree's dimensionality upon creation? So that I can do:
rtree<3, size_t, RTreeParameters, VertexIndexGetter>;
3 beging the dimension.
The only run-time parameters rtree can take are for balancing configuration. http://www.boost.org/doc/libs/1_65_1/libs/geometry/doc/html/geometry/spatial... Unless, again, something has changed and rtree can swallow-adapt `Value` type of any dimension. I'm sure Adam will chime in with further clarifications. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot Via Boost-users wrote:
On 27 September 2017 at 03:57, Florian Lindner <mailinglists@xgm.de> wrote:
Am 26.09.2017 um 14:40 schrieb Mateusz Loskot:
On 26 September 2017 at 04:02, Florian Lindner via Boost-users <boost-users@lists.boost.org> wrote:
We have a Vertex object, with a dimension determined at runtime. T This is not possible. Dimension is compile-time trait of any model in the Geometry, intrinsic or adapted. Unless my info is outdated. Ok, I expected that. Is there maybe a way to define the rtree's dimensionality upon creation? So that I can do:
rtree<3, size_t, RTreeParameters, VertexIndexGetter>;
3 beging the dimension.
The only run-time parameters rtree can take are for balancing configuration.
http://www.boost.org/doc/libs/1_65_1/libs/geometry/doc/html/geometry/spatial...
Unless, again, something has changed and rtree can swallow-adapt `Value` type of any dimension. I'm sure Adam will chime in with further clarifications. The rtree takes dimension from geometry::dimension of Value's Indexable Geometry in compile-time.
But I don't fully understand the problem. In the code above the dimension 3 is compile-time parameter, not run-time. The equivalent of the code above could therefore be e.g.: typedef bg::model::box<bg::model::point<3, double, bg::cs::cartesian>> box_type; rtree<std::pair<box_type, size_t>, RTreeParameters, ValueIndexableGetter> rt; Adam
participants (5)
-
Adam Wulkiewicz -
Dan Bloomquist -
Florian Lindner -
Mateusz Loskot -
The Maschine