Grasshopper - Strange rounding issue after rotating a rectangle

Hi,
Division CalcIssue.gh (42.4 KB)

I am fairly new to Grasshopper and have a question.

I have created a rectangle with a domain using a slider and negative and then fed that into a move and rotate component that shifts the rectangle up on the Z axis. I then have used a length and division component and output into some panels to check rounding.

For some strange reason some of the results during the rotate function create 2 results with a .0 single decimal place. When these are run through the Round component, despite being 8.0, they are rounded down to 7 on the Floor output and the one prior is rounded up on the Ceiling output. See attached file. Why is this happening when all the results are and should be 8.

Thanks

The text panel does some behind the scenes formatting of floating point numbers.


Division CalcIssue_re.gh (18.7 KB)

This explains the R format specifier:

-Kevin

2 Likes

Thanks for the explanation regarding the R format.

I’m using the format component with a custom value list to format numbers and circumvent rounding issues.

1 Like

Sorry, what do you mean by the R format specifier?

See the file I posted:
format

-Kevin

Yes I can see the R as a Format, but I do not understand entirely what that means. I think it means a “Real” number, which is a floating point number?

The division calculation should simply be dividing 80 by 10. It doesn’t really answer why a list of 80 or 80.0 in Grasshopper randomly decides that 80/10 or 80.0/10 is 8.00000000036 or 7.99999999973 - that is not mathematically correct. Is this a bug in the software?

It’s not a bug, it is caused by the way the computer handles floating point numbers internally.

See this post for more info:

-Kevin

2 Likes

Thanks Kevin for your patience on this. I appreciate you taking the time to find the article to point me to.

I generally use an Expression component for rounding (or embed the expression in an output parameter). Using text as floating point input to downstream components can be slow if you’re dealing with large amounts of data.

Here’s a comparison rounding 1,000,000 random numbers on my old iMac running Rhino V7.

Not as slow on a PC with comparable hardware specs also running V7.

The iMac performs much better with the V8 WIP.

Running the V8 WIP on the PC, using the Format component is actually faster than using an Expression :roll_eyes:

-Kevin

I haven’t noticed this being a problem in my applications yet but still thanks @kev.r it’s interesting.