CheckPrecision dissallowing precision values more negative than -8

[geoffder]

Is there a particular reason why the most negative precision value allowed by CheckPrecision (CPP) is -8? Coming from the perspective of using floats (as we do in Manifold), +8 is enough to cover the decimal places that they provide with an integer part of 0, if the significant figures begin immediately e.g. 0.1234, but floats are actually still able to provide their 6 to 7 digits at smaller decimals following zeroes. On the other side, stopping at -8 puts an (arbitrary?) limit on how big values can get before it is not possible to scale them down to fit into int64.

Ideally, I'd like to be able to use precisions as calculated by a function like below in order to scale up/down into int64, but CheckPrecision limits the working range of floats/doubles that can be used.

int precision(C2::PathsD paths) {
  auto rect = C2::GetBounds(paths);
  float size_x = glm::max(fabs(rect.left), fabs(rect.right));
  float size_y = glm::max(fabs(rect.bottom), fabs(rect.top));
  float size = glm::max(size_x, size_y);
  int magnitude = size > 0 ? (int)floor(log10(size))) : -1;
  // rough logic for decimals of small floats
  return 7 - magnitude;  // to give 8 places after the last insignificant figure

Is relaxing this constraint something that you would consider?

[AngusJohnson]

Hi Geoff. A good question 😁.
Basically, with very high degrees of coordinate precision (roughly ±10¹² after scaling and rounding), the accuracy of intersection point calculations will slowly degrade (eg see here).
This can be rectified by using alternative algorithms (see here), but these alternative algorithms will degrade performance. CheckPrecision doesn't use say ±12 precision (instead of ±8) because I'm anticipating that the non fractional part of coordinate values might be quite large too. Yes, this is a rather crude and not entirely reliable way of limiting extremes of precision (and preventing integer overflows). And yes, I'm open to suggestions on how this might be improved.
See also: http://www.angusj.com/clipper2/Docs/Overview.htm#coord_range

[geoffder]

Hello again Angus, thanks for the quick response. Sorry for glazing over the coordinate range section when I looked through the docs before posting, it would have given me a bit more context.

If I understand correctly, this limit of ±8 is set to prevent doubles from being scaled up too much in the name of representing their decimals such that they enter a range that degrades the algorithms performance. In the use-case that I have in mind, I would only be interested in using precision > 8 when the integer part of the floating point number is 0, thus not threatening to exceed Clipper's intended coordinate range.

On the other side with negative precision, at first I was just thinking of scaling down to fit arbitrarily large floats (whose decimal precision is meaningless at that point) into the range representable by int64, but now I understand that I should aim to scale down even further, to fit into the accurate coordinate range (~±1.0 × 10¹²).

Keeping the limited "safe" range of int64 in mind, I wonder if it would still be acceptable to loosen the hard limitation on double scaling with a note to the user (that hopefully they will not miss despite plenty of time on the doc site, like myself) similar to what the linked page already provides that they should scale down large values more than they would naively (like me) think they need to just to prevent capping on int64 max. Allowing the user to choose precision values in a way that doesn't necessarily linearly map a restricted coordinate space of doubles down into the restricted int64 space, instead allowing the window to slide as needed to fit in larger integer parts of floating point values.

[AngusJohnson]

Keeping the limited "safe" range of int64 in mind, I wonder if it would still be acceptable to loosen the hard limitation on double scaling with a note to the user (that hopefully they will not miss ...

I agree that all this should be better documented.
And the hard coded precison of ±8 should also be changed to a constant that could more easily be modified by users.

[geoffder]

Would it be appropriate to open PR that does this with a CLIPPER2_MAX_PRECISION option?

I'm planning to do that in the next repository update (and it will need to be done for all three languages).

Edit: Oops, sorry Geoff. I edited your post by mistake (instead of replying), and then deleted the wrong revision 😱.

[geoffder]

@AngusJohnson Ah ok, I'll not hit the PR button and leave it to you then (my changes are only for the CPP folder) 🙏.

[geoffder]

@AngusJohnson Are you still planning to add a definition that would allow setting the precision as mentioned? It's been a while, but I could update the old branch I had for CPP and PR it. I'm not familiar with how it would be done in C# and Pascal, but I could look at those implementations and figure it out if you want for all three to be updated at once.

[AngusJohnson]

Hi again Geoff.

Clipper2/CPP/Clipper2Lib/include/clipper2/clipper.core.h

Line 56 in 739f2e3

static const int MAX_DECIMAL_PRECISION = 8; // see https://github.com/AngusJohnson/Clipper2/discussions/564

are you wanting this redefined as a user modifiable int rather than a static const int?

[geoffder]

Ah I didn't look there, I was thinking it could be set with macro definition so users can pass a flag at build time, e.g. -DCLIPPER2_MAX_DECIMAL_PRECISION=8. Thanks again for getting back.

[geoffder]

For reference, here is the diff on the old branch I made when I opened this issue/discussion. geoffder/Clipper2@main...geoffder:Clipper2:max-precision-flag

[geoffder]

@AngusJohnson I'm guilty of being inactive in OSS lately, but I thought I'd check back in on this after remembering it in case it went under the radar. If this was updated to be user configurable then I might finally try and touch up manifolds 2D API to make it a bit closer to the 3D than it currently is (increasing the range of acceptable coordinate values). Sorry to be a nuisance and resurrect an old thread!