Subject: Re: [boost] GGL Review
From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2009-11-17 12:36:46
On Tue, Nov 17, 2009 at 12:23 PM, Phil Endecott
> Jonathan Franklin wrote:
>> On Tue, Nov 17, 2009 at 6:35 AM, Brandon Kohn <blkohn_at_[hidden]> wrote:
>>> My own view
>>> is that something that only works part of the time really doesn't work.
>> I'm sure that's great for whatever you do. Â It is valid in many use cases.
>> The visualization software that I work on, on the other hand, prefers
>> speed over making sure that point p1 is provably inside or outside the
>> box. Â If it's *that* close, then it doesn't matter.
> Hi Jonathan,
> Do please have a look at the paper that I linked to before, and in
> particular the figure at the top of the second page:
> Â http://www.mpi-inf.mpg.de/~kettner/pub/nonrobust_cgta_06.pdf
> Two points:
> 1. Failures may not occur only in cases when things are very close. Â A
> problematic input may cause the output to be grossly wrong.
> 2. You may not get a wrong answer; the program might instead segfault or
> loop forever.
This discussion raises some important implementation considerations,
but for the purposes of this review, the discussion should simply be
"Are we requiring that the implementation be provably 100% robust and
100% numerically stable before acceptance?".
If the answer to that is yes, then I think we are holding GGL at a
*much* higher standard than previously accepted libraries (I'm not
talking about any specific library). Note that even CGAL, a highly
regarded library failed that paper's tests.
I believe the interfaces and concepts should be what is discussed.
Implementation bugs and optimizations can come later if the interfaces
are well designed.
I'm hoping to do a full review within a day or two, but I just wanted
to add my two cents to this discussion.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk