Brandon Kohn wrote: There are many buggy floating point boolean op libraries out there. Why do we need another?
I would like to ask you to refrain from spreading FUD with regards to
Hartmut Kaiser wrote: the
library under review without any concrete proof.
Hartmut, I'm unhappy that you as review manager made that comment. You ought to be more impartial. I don't think it's unreasonable to call the FP robustness issues "bugs". I think it's very likely that GGL has these issues when used with FP coordinates, and I don't accept your "concrete proof" requirement for making that allegation. The library's approach seems to be, "if you're not happy with undefined behaviour, use an arbitrary-precision coordinate type". Please correct me if I'm wrong, but I believe the library doesn't provide any way to hide the arbitrary-precision type and the type conversions from the user as an implementation detail, nor does it have a mechanism to fallback only when it detects a problem with the FP calculation, nor have any benchmarks been done on the arbitrary-precision case.
I'm sorry to disagree. The OP stated: <quote> There are many buggy floating point boolean op libraries out there. </quote> So far so good, I might agree with this. But then: <quote> Why do we need another? </quote> which refers to the library under review, clearly saying that it is buggy, no? Did I misunderstand that? If yes, I apologize. Please don't get me wrong. I've been working in GIS industry long enough to fully understand the problems of robustness and arithmetic stability (or the lack of) of geometry algorithms. That's not my point. I reacted to the unsupported claim of a reviewer stating the library we're currently looking at is buggy. It might very much be GGL has those bugs as you're silently prejudicing (is that an English verb?). But we're not here to point fingers, but to help improving design, implementation, and if needed, to pinpoint bugs. Broad allegations don't help with this. I'm not going to argue here about your statement arbitrary-precision has to be an implementation detail. I accept this as your personal opinion, but whether this should be a requirement for GGL has to be decided by the reviewers. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com