Rounding values bug

I am pushing left panel values through round(x,1) expression.
See the same -13.25 value (1,2,3,18,19.20) giving different results.

:thinking: How about this?!

This is even worse than I thought. The same native rounding component reads multiple 2.5 values as 2 or 3. See eg. 59 and 71.

This is REALLY BAD.

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.

Hope this helps.

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.

Do you want to upload your list of values? I’ll have a look at it.

The list of values changes constantly. It comes from area or volume momentum for hundreds of surfaces.
I have prepared this example:


Strangely, it gives me that errors with X, sometimes with x,1 rounding.

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.

Sorry @Piotr, got pulled into doing other work.

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…

Hope this helps…

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.


Still, i would appreciate some comment from McNeel how to deal for real with this problem.

I’m having a similar rounding issue as above.

Rounding 1.125 to the nearest two decimals, I’m expecting 1.13.

All of these use: round(x, 2) ,but only the Python version is getting the result I’m expecting.

Am I doing something wrong?

round.gh (10.1 KB)

1 Like

c# ,VB, Python3 give the result: 1.12

Python2.7, Ironpython give the result: 1.13

The correct one is 1.13

Thanks for the comparison in other languages -this helped get me on the right track!

It seems like this is more a matter of my understanding of computer science than a Grasshopper issue. I was able to find some more on the issue here