Subject: Re: [boost] GGL Review
From: Fernando Cacciola (fernando.cacciola_at_[hidden])
Date: 2009-11-18 23:21:20
[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
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
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.
-- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk