About F5/6 and using the centroid as rotation origin

Please use this forum to post feedback and suggestions related to QCAD.

Moderator: andrew

Post Reply
CVH
Premier Member
Posts: 4954
Joined: Wed Sep 27, 2017 4:17 pm

About F5/6 and using the centroid as rotation origin

Post by CVH » Tue Oct 08, 2024 3:54 pm

Andrew,
As explained in the related post, F5/6 use the center of the bounding box of the current selection.
Then F6 does not counteract F5 ... In al cases.

The solution is to rotate the selection around the centroid of for example a convex hull ... A polygon.

I saw you implementing the centroid of a polygon: commit e98d5f6
This is basically the Shoelace algorithm.
Essentially exactly the same as InfoAreaCentroid.prototype.getPolygonAreaCentroid(polygon)

BUT:
For a large number of tiny segments the naive running sum can suffer from (catastrophic) digit cancellation.
Also: What Every Computer Scientist Should Know About Floating-Point Arithmetic
At some point you start adding (subtracting) small values to already much larger values ...
... While loosing some to more significant digits in the process.
I experienced the same issue when coding the Centroids tools available under Misc .. Information .. 2D Centroids.
Signed area and Centroid position are hardened again digit cancellation as good as it can be.

The solution came from 'A generalized Kahan–Babuška-Summation-Algorithm' proposed by Klein.
Advantages are: Single loop trough and second-order compensation.
Perfectly usable and steady results for long (unsorted) lists of arbitrary values.
Typically the difference of another order of values is a few ULP's off.
The naive running sum may exhibit errors expressed in % of a unit.
The downside is that we have to collect the values in a sometimes vast array.

This robust way of summing large sets of arbitrary values is already at hand and implemented under:
InfoCentroids.prototype.getRunningSumKBK(list)
When things get more complex than 1+1+2-3 I tend to rely on the certainty of result in every code I write.


In preface of what will be included in an upcoming release I did some test, ...
... Comparing the Shoelace algorithm with the naive summing and the centroid returned by the area centroid tools.
With a small set of very distinct vertices the difference is usually less than RS.PointTolerance.
It starts to matter for a larger set and then even more with for example the approximation of a Spline or an Ellipse as a polygon.
The result is no longer steady at any rotation and it is also related to its position in the plane.

To avoid this last issue, 2D Centroids project the shape in question so that it encircles the origin and projects the result back.

Regards,
CVH

Post Reply

Return to “QCAD Suggestions and Feedback”