I think this discussion has deviated a bit of course from what Jonathan and I were discussing. I should have been a bit more explicit when I said 'Why do we need another buggy library.'. If you follow our discussion, I started by stating my concerns about the floating point robustness of GGL with respect to the boolean operations. The point I was trying to make was that I believe that GGL would be the first library of its kind in Boost that walks the line of being provably correct (WRT boolean operations with FP coordinates) and that this perhaps means that more care needs to be taken in reviewing it. Jonathan replied that for his needs it didn't matter if the algorithms were correct, only that they worked most of the time. My own view is that something that only works part of the time really doesn't work. From these two polarized views came my statement which was essentially meant to say: Why would we really want an algorithm that only works some/most of the time in Boost? Of course a good argument to that is that we can use GMP as the coordinate type if we need the added stability. Fine. This still comes back to my original post/reply that (IMO) these considerations are treading new ground in a review process and that the author of the library needs to address these concerns by providing tests proving any (implied) claims of an algorithm's correctness. If this cannot be done at the start, perhaps the boolean operations should be omitted until such a time as they can be properly proven. Luke seems to have much expertise in the area of boolean operations, and has already suggested a battery of tests. I think this would be an excellent place to start. Regards, Brandon