Subject: Re: [boost] GGL Review
From: Barend Gehrels (barend_at_[hidden])
Date: 2009-11-16 13:53:02
> I'm referring to OpenGL's CSG boolean ops and PolyBoolean, both of
> which routinely fail in an application with which I work. (It requires
> partitioning space by iteratively subtracting isovists from a triangle
> partition of a polygon with holes.) I have read the CGAL also has
> issues for similar reasons.
Thanks, I didn't tested them nor the use case you describe, but would be
happy to test it (I mean: the use case)
>> Numerical floating point issues can be addressed using arbitrary
>> arithmetic types, and besides that other measures can be taken using
>> the default floating point types.
> As for GGL's working with arbitrary arithmetic types, I would have to
> take your word for it. I have found a few bits in the code that seem
> to be converting to double.. and so I'm not so sure about your claim.
Sure, you are right here. I think I mentioned this in another mail but
will summarize it here with references.
I was talking about how the design is setup. We've designed it with
strategies and (optional) calculation types. That design is used in e.g.
Because the numeric_adaptor (this was another posting on the boost list)
was not 100% completed and because it seems to have much overlap with
Boost.Math bindings, we chose here for showing the design in some
algorithms and we didn't yet apply it everywhere.
So it is not yet applied to intersection indeed, and as the focus of the
whole library is currently on intersections, I admit that I regret that
and we should have chosen to apply it there.
Anyway, I hope you'll believe me thus and please look in area,
http://tinyurl.com/ggl-area1 and http://tinyurl.com/ggl-area2 where it
is applied (it is also applied in centroid and distance). It will be in
(a.o.) intersections too.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk