Re: [boost] GGL Review

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
<spam_from_boost_dev_at_[hidden]> wrote:
> 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.

--Michael Fawcett