Am Monday 16 November 2009 15:06:54 schrieb Brandon Kohn:
Phil Endecott wrote:
The other controversial implementation issue is floating-point robustness. I'm still not clear what the position of this library is on that. Are we just given assurances that it seems to be robust in real-world use, or is it believed that it actually is certainly robust? I expected to see this discussed in the library documentation, but I don't see anything - maybe I've missed it. If it is "believed to be robust in real-world use", it would be helpful to describe the possible failure modes (e.g. segfault, runs forever, or just outputs the wrong answer.)
This is an issue that troubles me as well. I think that a floating point computational geometry library is possibly a first for Boost in that you often have heuristics rather than algorithms due to the fuzzy effect of using floating types in comparison predicates. One of the more useful features of the library (GGL) would of course be the boolean operations. The problem however is clearly going to be robustness. I have never encountered a robust floating point boolean operation library in my 9 years of working in the geometry domain.
I think the question of this review is not whether some algorithms in GGL have limitations, as long as they are documented, but if the concepts and algorithm/strategy interface is sufficient to allow the implementation of specialized algorithms. is this the case? luke seems to be willing to integrate his Boost.Robust2DIntegerPolygon into GGL, but he also seems to have some concerns if he'll be able to do that using GGL's polygon representation. those should be addressed before GGL is accepted. I was surprised that Polygon was accepted on a 6 to 4 vote, even though a "geometry core" library was right around the corner. I don't think people were aware of that during the review, iirc there was a lot of talk about "waiting" for a generic geometry library. a future review process should make it possible to postpone or reschedule a review.