Hi

So basically I have a group of polys wich are supposed to be identical, see pic (1 copied several times with some translation and rotation operations) and inside a foreach sop (the old one)I run a check on the area of each polygon to see if its equal to a certain value and if so I put the primitive in a group, I do this because sometimes the group contains some polys that are much bigger than the ones you can see in the picture.

But when I run this foreach some polygons get deleted even if they shouldn't because they are equal to the other ones wich arent getting deleted…

Now looking in the geospreadsheet you can see that some polys have an area of 1.365 and few other of 1.36499, so I set the condition for the grouping to be @area <= …the value but for some reasons other polys get deleted…

I searched for a round function but the only one I could find is rint() wich rounds to the closest integer

Any method of fixing that round thing? I meanwhy the same numbers multiplied togher sometimes gives 1.365 and few other 1.36499?

Thanks

SteN
1 copied several times with some translation and rotation operations … Any method of fixing that round thing? I meanwhy the same numbers multiplied togher sometimes gives 1.365 and few other 1.36499?

Because floating-point numbers use a finite number of bits to represent the point positions, if you rotate a polygon, its area changes by very small amounts, so the equality comparison only succeeds for the few cases where the area happens to be close enough to the value being compared that it gets snapped to the same floating-point value. That last part is why adding more bits of precision doesn't help; the area may be closer to the original area, but it also needs to be closer in order to still be considered equal.

Usually, if people need to check whether floating-point numbers are approximately equal, they'll use a tolerance, e.g. by checking if abs(@area - other_value) < 1e-6, though you have to be careful to choose and apply the tolerance in a way that fits the scenario, because some cases will have more roundoff error than others. In the cases where things need to be perfect and the occasional false positive/negative is not acceptable, you have to avoid any comparisons that might depend on the roundoff error at all, e.g. add all of the originally copied primitives into a group, so that you don't have to compare the area at all.

Perhaps could also move the decimal point down so rint() will work.

The problem with rounding to integers is that if you have values around 0.5, 1.5, etc, tiny variations due to roundoff error can still result in incorrect comparisons, regardless of how you shift the decimal point before rounding.

Yea I understand. Thanks for the explanations.