Subject: Re: [boost] GGL Review
From: Jonathan Franklin (franklin.jonathan_at_[hidden])
Date: 2009-11-16 15:50:59
On Mon, Nov 16, 2009 at 12:35 PM, Simonson, Lucanus J
>> I was under the impression that Luc was basing his reservations on
>> robustness issues due to floating point limitations. Perhaps I
>> misread, or missed a point or two.
> Barend requires that the polygon provide a type with stl container interfaces that holds its holes. This prevents it from adapting the majority of polygon data types (including my own) that don't provide direct acceess to private members. My request was that he make the interface for his polygon concept more generic.
Sorry, I was remembering this comment from the 13th or so, and
confused it w/ the current discussion:
Simonson, Lucanus J wrote:
> Upon reflection the polygon formation algorithm requires robust comparisions in the tree, which floating point arithmetic cannot provide, so the code cannot be adpated to solve the problem with holes in GGL.
> If you bother to look at my submission you will find that the interfaces for the geometry concepts are fully generic, and ...
This isn't about your library. However, coming out of boostcon, it
was at least *my* understanding that you were supposed to *at least*
work out these issues w/ Barends prior to submitting your library for
review. That clearly didn't happen, so let's just move on.
It would be nice if we could just focus on reviewing GGL for its merits.
> I'd also like to point out that fixed point is not a VSLI specific requirement, nor is robustness. Some GIS applications use fixed point coordinates and closed source solutions for polygon clipping that are robust and fast are used in VLSI all the time.
I totally agree. I have done some work in the past where we needed
precise lat/lon computations, and used fixed point.
I'm just fighting against the "it has to be 100% numerically stable a
la fixed point" mentality that has been prevalent, because it doesn't
serve my (and many others) needs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk