Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009

Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2009-09-02 22:32:31

Hartmut Kaiser wrote:
> I'm concerned about whether the library is really sufficiently
> generic for the need of a multitude of users. Especially the fact of
> not being able to use arbitrary precision floating point types is a
> absolute show stopper for me. In my experience geometric stability is
> the main source of problems when dealing with real world GIS data.
> This isn't something solvable by being constrained to fixed integer
> types. 

Hartmut is right, fixed point doesn't solve the problem because conversion back to floating point may lose precision.  Hartmut is also right that not being able to use arbitrary precision floating point types is unacceptable.

I can easily detect floating point types and disable snap rounding and any other integer specific code.  This would make Boost.Polygon work with float and double whereas now it generally does not.  However such usage would not be robust, just like CGAL is not robust with limited precision floating point.  It would also allow the use of arbitrary precision floating point which would be robust.  Making these changes is not too difficult for me, and if the review manager decides to make it a condition for acceptance I can add it to the list of tasks I need to complete before the library is added to boost.  Eliminating MSVC warnings and c-style casts will probably take more time than disabling snap rounding and validating the floating point instantiation.

> My real concern comes from the performance numbers presented by Barend
> showing Polygon to be more than 10 times slower than comparable
> geometry libraries. Luke gave some response to that. What I find
> somewhat non-satisfactory is that the numbers may be skewed by
> selecting a very particular field of highlighted algorithms (as
> pointed out by Luke). So I would like to see some numbers produced by
> Lucanus, allowing to get a better and more objective sense for how
> Polygon measures up if compared to others. 

The benchmarks I presented at boostcon do show that for small inputs I am slower than GPC, but faster than CGAL.  Barend's benchmarks confirm this.  I figured that falling generally between CGAL and GPC was reasonable performance.  Both GPC and my implementation have sub-optimal scaling, but different worst case inputs.

Thanks Harmut for your review.  You raise some good points.
Luke