Should the C# ClipperD implementation really exist?

[mikehoyle]

Per the documentation FAQ here, and my own tests, ClipperD accepts floating point values (which can contain decimal points, and are very often used for that purpose), yet translates them to integers on the backend.

I made the incorrect assumption going into my use of the library that the meaning of the FAQ is that the backend translation to integers must be done in a way that would preserve decimals in the result (for example, by multiplying by some precision value) -- otherwise, why support doubles at all? Instead, the library truncates all decimals and ignores any intersections smaller than an integer granularity.

While my true opinion is it would be very useful to be able to actually operate on floating point values (even if there is a very small well-known concession of precision that inherently comes with working with floating point values), I won't come into the forum requesting work I'm not prepared to do myself.

Instead I can at least beg the question: Is ClipperD an intuitive or useful tool to have present in the library? It provides the appearance of functionality it doesn't actually give (to calculate clips on polygons with floating point vertices). The only documentation of background decimal truncation is in the website's FAQ, which even still isn't particularly intuitive.

Unfortunately it seems Clipper2 just went past v1.0, so the only suggestion I can make is this: It should be boldly, clearly stated in the documentation that a PointD is a double representation of an integer, and ClipperD exclusively receives and returns integer values, and will ignore any decimal points. I'm happy to be the one that adds this, but I'd like to raise the idea up for discussion first.

If it seems I've misunderstood something about this library, please let me know.

[AngusJohnson]

Hi Mike.

Firstly, thank you for your thoughtful feedback.

By far the most common question I got concering Clipper1 was about floating point coordinates. It seemed to me that many users either didn't understand that Clipper used integers for very good reasons, or they failed to appreciate just how easy it is to convert floating point coordinates to and from integers. So, I figured I'd make this easier still in Clipper2.

However, your question here has prompted me to look again at how ClipperD is implemented and I notice there's an unintended difference between the Delphi version (where I do almost all Clipper development) and in my C++ and C# translations. In Delphi, the ClipperD constuctor scales coordinates (up and down) the by 2 decimal places by default. Yet in C++ and C# there's no default scaling. So, while I think the Delphi 2 dp default is better, the ClipperD constructor in all languages allows the user to specify their perferred scaling precision.

I made the incorrect assumption going into my use of the library that the meaning of the FAQ is that the backend translation to integers must be done in a way that would preserve decimals in the result

Well, it does if you use the constuctor's optional precision parameter 😁.

Instead, the library truncates all decimals and ignores any intersections smaller than an integer granularity.

Again, only if you use the current default precision (which I intend to correct).

If it seems I've misunderstood something about this library, please let me know.

I think so 🙏, and I have done so 😎😁👍.

[mikehoyle]

Ah of course! I was looking for parameters on Execute but not on ClipperD itself. I apologize for the misunderstanding, thank you for walking through it for me.