Might not be a bug, but an issue with how values are displayed. You can show the actual values using the expression component and using Format("{0:R}",x). I’ve attached an image showing what the difference is.
I’m not sure whether it helps. It is an information, but I still don’t know how to deal with the fact that I am receiving two different roundings to the same value, using same method.
Thanks for your time, I am desperately looking for a solution. I can’t work with this bug anymore. rounding bug.gh (21.0 KB)
PS. This is a part of a large file that does lot’s of 3D operations. Hopefully, it will help.
I think there’s two things happening. First, using Round component will round 0.5 intervals to ceiling (of the desired decimal length), i.e. 0.5 -> 1.0, or 0.55 -> 0.56. Values of 0.49 will round to the floor, i.e. 0.
By default round(x) will round to the floor from 0.5. It must be how the component was implemented.
The second thing is that some of your values aren’t exact matches; for example one 2.5 value might be 2.5 while another might be 2.49999. In this case they will round differently as 2.49999 is mathematically closer to the floor value (i.e. 2.0) than it is the ceiling value. This is why two values that look the same are being rounded differently, and the importance of using the “unrounded” values. I’ve attached an image that hopefully highlights what I’m talking about.
At the end of the day it might be worth developing your own rounding so that the numbers are being treated consistently as you need. Could be as simple as conducting two sets of rounding perhaps? Really depends on what you’re working with or your tolerances. In my industry (construction) there is functionally little difference between 3mm and 2mm so its not a problem if they round up or down. For something like Jewellery maybe you need more than that…
The sorting things is important for restoring the structural order of my model after splitting it.
I still don’t know how to deal with my problem and it doesn’t explain the image No2.
Thanks for trying, though.
I broke the system. I have created the cluster that forces solution by rounding to (x,2) first and then deconstructing the value, leaving (x,1).
It has nothing to do with precision but it is consistent (or so it seems to be). Tested on a 70 models.