Hi Steve, [disclaimer: I'm just responding to current traffic totally out of thread and without knowing the current state of the GGL]
Using floating-point filters the speed can be competitive with the naive algorithm, but without the crashes.
There is in fact something VERY important to add here: I know for a fact, since I have carefully looked into it, that Boost.Polygon is 100% robust when used with integer coordinates provided the user properly sets the "extended integer type" needed by the filtering mechanism (which is already set when the coordinate type is "int" and sizeof(long) == 2*sizeof(int)). IOW, Boost.Polygon uses a filter, just like CGAL. This is why I specifically said that the library should be considered to be restricted to integer coordinates. While this was not brought up during the formal review, it was in the preceding discussions. I was aware of this and this *fundamental library property* was the most important reason why I accepted the library into boost. If you google the developers list you should find my very lenghly explanations about why this is an absolute requirement, why GTL (at that time) was already meeting it, and why GGL was not. I even sketched a general approach that could be followed to make GGL robust with floating point coordinates (essentially just explaining what a floating point filter is and how it works). FWIW, Barend is very well aware of all this and has always been more than willing to do any required fixing. What happened is that I never had all the time needed to dedicatedly give him the neccesary guidance, so the issue is probably still unresolved. Best -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com