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
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. John