Subject: Re: [boost] GGL Review
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2009-11-16 16:06:45
> Hartmut Kaiser wrote:
> >> Brandon Kohn wrote:
> >> There
> >> are many buggy floating point boolean op libraries out there. Why do
> >> need another?
> > I would like to ask you to refrain from spreading FUD with regards to
> > 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:
There are many buggy floating point boolean op libraries out there.
So far so good, I might agree with this. But then:
Why do we need another?
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
GGL Review Manager
Meet me at BoostCon
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk