Subject: Re: [boost] Formal Review: Boost.Polygon starts today August 24, 2009
From: John Phillips (phillips_at_[hidden])
Date: 2009-09-01 17:03:37
Simonson, Lucanus J wrote:
> I can implement a transparent floating point to fixed point
> conversion wrapping the algorithm that is integer only. This should
> allow transparent use of the algorithm with floating point
> coordinates and no more loss of precision than floating point
> calculations themselves would produce.
> Thanks Jeff, Luke
You have made variations of this assertion a few times in this
thread, and I wanted to point out one problem with it.
The distribution of the integers is not the same as the distribution
of the floating point numbers. It is true that an x-bit integer has
about as many distinct values as an x-bit floating point number. (Even
more, depending on the representation used.) However, those integers are
evenly distributed along the number line, and the floating point values
are not. This will not cause a problem in many applications, but in any
setting where large and small scales mix (such as polygons that are just
off of regular, but need to be precisely defined; or systems that mix
large and small polygons) there will be no scaling for the integers that
both preserves the needed dynamic range and the needed precision. So the
user will be forced to choose between overflow errors or lost precision.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk