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-01 17:31:31

John Phillips wrote: 
>    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. 

This is true, of course.  However, in such systems where large and small scales mix, floating point is itself problematic.  When snapping a large scale intersection point to the floating point grid it may cause a long edge to sweep arbitrarily far, potentially crossing to the other side of large numbers over vertices at a small scale near the floating point origin.  I would say that in general planar geometry has the property that precision of all points is equally important, and that floating point just provides the convenience of ignoring scale.  We mix large and small scale features in VLSI, our package layer looks like a PCB, while the metal layers below are many orders of magnitude smaller.  If you can't represent the small features in your integer type because the extents of your large features are simply too huge you have many many many orders of magnitude difference between them, enough that by definition you won't be happy with floating point calculations either.

Good question, thanks,
Luke