Re: [Boost-users] [polygon] Valgrind errors when normalizing any angle polygons

Subject: Re: [Boost-users] [polygon] Valgrind errors when normalizing any angle polygons
From: Josh Pieper (jpieper_at_[hidden])
Date: 2010-11-05 05:43:37

On Thu, Nov 4, 2010 at 10:28 PM, Simonson, Lucanus J
<lucanus.j.simonson_at_[hidden]> wrote:
> No, I fully expect the library may crash or exhibit other undefined behaviors if coordinates are too large and gmp is not used.  If the coordinates are small enough that the numerator and denominator of the line intersection equation fit in the floating point representation without roundoff then the library may work correctly without the need for gmp, but in general I don't advise using the library without gmp.  You will quickly find that in order to avoid rounding error issues you want to scale your data up, which won't work if you are trying to keep things within a ~16 bit range.

Would it be worth it to BOOST_ASSERT if data too large for the given
types is passed in without gmp enabled?  I would expect that an
assertion is probably more desirable than undefined behavior.

For a platform with a given maximum floating point resolution, what is
the maximum integral value that may be used without triggering
instability?  On this system, a long double has 64 bits of mantissa.
Does that mean the gmp-less boost::polygon is limited to 64/4 = 16
bits of resolution?  We're using gmp now, so this is purely for my
curiosity.

> I just checked into the trunk today a couple changes that should make the library more reliable without the use of gmp.  My version number for the checkin is 66403.  The sandbox version is older than the 1.44 release.  I stopped syncing the sandbox once I merged to the release branch and now do all development on the trunk.  Included in this checkin were several fixes for resizing that didn't make it in time for the 1.45 release.  If you plan to use resizing you should update.
>
>> Is this merely a mis-use of the API?
>
> I would say yes, but only because you expected the library to be reliable without using gmp.  Right now I can't provide that and make no promises about reliability if gmp is not used.

Fair enough.

> You mentioned a number of oddities but describe only one.  What else have you run into?

We had hoped to use resizing, ran into the aforementioned problems,
then ran into different ones after trying trunk.  I believe they were
related to using beveled corners, but I still need to reduce our
problems to minimal cases.

Thanks for the quick reply!

Regards,
Josh