Ticket #8254 (closed Bugs: fixed)
Faulty intersection calculation
Reported by: | sascha.knell@… | Owned by: | barendgehrels |
---|---|---|---|
Milestone: | To Be Determined | Component: | geometry |
Version: | Boost 1.53.0 | Severity: | Showstopper |
Keywords: | Cc: |
Description
I encountered a (supposed) bug in the boost::geometry::intersection functionality.
The calculation of the intersection of a tiny triangle lying in a considerably bigger trapezoid where one edge of the triangle lies (within floating point precision) on one edge of the trapezoid results in an intersection which consists of the original trapezoid with one additional node on one of its sides.
The geometry is given in a C test routine attached to this ticked. The actual call of the intersection functionality is conducted in a C++ wrapper routine, which is also attached. The bug occurred on Mountain Lion with the llvm-gcc-4.2 compiler.
Attachments
Change History
comment:1 Changed 3 years ago by barendgehrels
I reproduce this. Using MSVC the output is correct, according to the input. Using gcc (I'm using 4.4.5) I get similar output as you give.
I will have a closer look, but I will have to debug differently because it's not occuring in MSVC.
comment:2 Changed 3 years ago by barendgehrels
- Status changed from new to closed
- Resolution set to fixed
Fixed. The underlying sections (used for performance) were too small in rare cases. Made them a tiny bit larger, such that intersections are not missed by this. By change this was also necessary for one of my own testcases, for multi-point buffers.
Fixed in trunk, will be released in Boost 1.54