Maximizing precision with floating point data

[ramcdona]

I'm trying to understand best practices with Clipper2. My original point data is floating point data. I would like to maximize the precision in my results from Clipper. I generally understand how the precision parameter works with ClipperD -- the default value is 2, the maximum is 8.

Precision = 8 seems to be a limit that is based on some assumption of the magnitude of your double values. However, the scale factor is set before Clipper has received any path data (and therefore can not have checked a bounding box to determine the magnitude of the numbers).

Part of me is tempted to scale my doubles before feeding them into PathsD, but that really seems counter to the way things are supposed to work. If I'm going to scale my numbers, I might as well scale them to +=1e12 and use Clipper64 (right?).

As a user, I expected Clipper to defer scaling my D input until after I was done AddSubject()'ing it (and it could therefore use a bounding box to come up with an appropriate shift and scale). Or allow me to specify the magnitude of numbers I plan on using.

What is the best practice way to obtain maximum precision when dealing with Boolean operations on floating point data?

Thanks again for an outstanding library.

[AngusJohnson]

This is somewhat complicated so I hope my explanation below makes some sense ...

Clipping must be done using integer coordinates to maintain numerical robustness. So the ClipperD class is really just a wrapper around Clipper64, and scales float values in input path coordinates to integer values (and later descales the solution). But there must be a limit to the available precision because integers must fit comfortably inside Int64 (and perform Int64 addition and subtraction without overflow). So in theory at least these scaled integer values could be +/-1 x 10¹⁹.

However the function in the library that calculates intersections degrades (ie becomes less accurate) when integer values are much greater than +/-1 x 10¹². (I could make this function more accurate but doing so significantly slows performance.) So the compromise is to limit the amount of scaling (ie when converting floats to integers) to try and keep integers inside this +/-1 x 10¹² range. And there's an undocumented assumption that by limiting the decimal precision to 8 (ie scaling 100,000,000), it's unlikely that integer values will significantly exceed a range where (intersection point calculation) precision becomes significantly compromised.

[ramcdona]

Thanks for going through that all in one place. It pretty much matches the understanding I had come to.

I guess the mysterious part to me is the assumed magnitude of the double precision numbers that lead to the precision limit.

My program is mainly used to model aircraft and other things that fly. The smallest to largest flight vehicles span about three orders of magnitude (perhaps a couple more if we go down to small insects). Likewise, my program does not specify units -- so users are free to choose. Choosing mm to m adds three more orders of magnitude.

While most people would not use meters to model a small aircraft (or mm for a large one), it is certainly possible. In the end, 'reasonable' scales of models can vary by six or eight orders of magnitude.

I guess this is why I expected to see the double conversion happen with some knowledge of the expected magnitude of the numbers.

I agree that my best bet is to continue using Clipper64 and to just take care of the conversion myself. Done! That even requires less changes as I port from Clipper1.

I think an addition to the documentation that states the assumed range of floating point numbers used to set the precision limits would help clarify things. Perhaps also include a note 'If this assumed range does not apply to you, you should use Clipper64 and scale things yourself.'

[olologin]

But at the same time we must not scale it to a too small integer range, because some distinct floating points (but very close to each other) will merge into one integer point, or maybe even introduce self-intersections. Right?