Hi, my name is Tinko Bartels, I'm studying to get a Master's degree in Mathematics at TU Berlin. I'm interested to work on Boost Geometry. I'm working at the university for a couple of years on C++ projects that rely on Boost libraries, most notably Boost.Geometry. Our work involves the computation of exact covers of spaces with boxes. This motivated my idea to add support to void union_(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection) void sym_difference(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection) void difference(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection) for Geometry1=Geometry2=box and Collection is a collection of boxes. Since I have no merged contributions to open source projects to refer to, I could, for example, provide an implementation of the difference method for types adhering to the box concept and a collection of boxes as output_collection. Since the results of those operations in terms of exact covers of the resulting space with boxes are not uniquely defined and the implementation should take less than 3 months, additional strategies for these specializations of the above algorithms could be added as future milestones. If this endeavor is considered worthwhile by potential mentors, I would get started on writing a proposal right away. Kind regards, Tinko Bartels -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
Hi Tinko,
I am interested to serve as a mentor to that project.
Looking forward to your proposal and implementation.
Best,
Vissarion.
On 16 March 2018 at 01:11, Tinko Bartels via Boost
Hi,
my name is Tinko Bartels, I'm studying to get a Master's degree in Mathematics at TU Berlin. I'm interested to work on Boost Geometry. I'm working at the university for a couple of years on C++ projects that rely on Boost libraries, most notably Boost.Geometry. Our work involves the computation of exact covers of spaces with boxes. This motivated my idea to add support to
void union_(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection) void sym_difference(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection) void difference(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection)
for
Geometry1=Geometry2=box and Collection is a collection of boxes.
Since I have no merged contributions to open source projects to refer to, I could, for example, provide an implementation of the difference method for types adhering to the box concept and a collection of boxes as output_collection.
Since the results of those operations in terms of exact covers of the resulting space with boxes are not uniquely defined and the implementation should take less than 3 months, additional strategies for these specializations of the above algorithms could be added as future milestones.
If this endeavor is considered worthwhile by potential mentors, I would get started on writing a proposal right away.
Kind regards, Tinko Bartels
-- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Tinko, Tinko Bartels Via Boost wrote:
Hi,
my name is Tinko Bartels, I'm studying to get a Master's degree in Mathematics at TU Berlin. I'm interested to work on Boost Geometry. I'm working at the university for a couple of years on C++ projects that rely on Boost libraries, most notably Boost.Geometry. Our work involves the computation of exact covers of spaces with boxes. This motivated my idea to add support to
void union_(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection) void sym_difference(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection) void difference(Geometry1 const & geometry1, Geometry2 const & geometry2, Collection & output_collection)
for
Geometry1=Geometry2=box and Collection is a collection of boxes.
That's interesting. I'm also willing to be a mentor, in case Vissarion had too much work with other projects. Out of curiosity could you give some example or is the behavior not fully known yet? For instance what would be the results of the above functions if we had 2 boxes overlapping each other with a small area near the vertex? E.g. BOX(0 0, 5 5) and BOX(4 4, 9 9). Adam
First of all, thank you, to Adam and Vissarion for showing interest and offering mentorship. I will start writing a proposal. Boost - Dev mailing list wrote
Out of curiosity could you give some example or is the behavior not fully known yet? For instance what would be the results of the above functions if we had 2 boxes overlapping each other with a small area near the vertex? E.g. BOX(0 0, 5 5) and BOX(4 4, 9 9).
That would depend on what is considered part of the box, i.e. whether BOX(0 0, 5 5) is [0,5]x[0,5] or [0,5)x[0,5). Because interest has been shown, I have published a quick implementation of difference for (box, box, container<box>) on GitHub ( https://github.com/tinko92/boost_geometry_difference_demo ). I have chosen to consider boxes closed on all ends, and my result for your example boxes is (assuming integer coordinates): BOX(0 0, 5 5) minus BOX(4 4, 9 9) results in the two boxes: BOX(0 0, 3 5) and BOX(4 0, 5 3). For floating point, the convention of closed intervals is a little awkward, since "-1" from integers doesn't translate directly to floats, so maybe half-open intervals would make more sense there. For union I would expect the result to be three boxes, BOX(0 0, 3 5), BOX(4 0, 5 3) and BOX(4 4, 9 9) and for sym_difference, I would expect a list of four boxes: BOX(0 0, 3 5), BOX(4 0, 5 3), BOX(6 4, 9 9) and BOX(4 6, 5 9). Another awkward case is BOX(0 0, 5 5) minus BOX( 1 1, 4 4) which would result in 4 thin slices of thickness 0, which makes them invalid with respect to boost::geometry::is_valid, so I've added a parameter to the demo that determines whether I want to allow this or not. Of course, those solutions are not uniquely determined and assume that the resulting list of boxes should be an exact cover of the result set and not allow intersections in the result. It might be sensible to make this more configurable to give a potential user of those methods more freedom to express his preferences with regard to those edge cases. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html
participants (3)
-
Adam Wulkiewicz -
Tinko Bartels -
Vissarion Fisikopoulos