Slider Accuracy

Replies to This Discussion

Permalink Reply by Hannes Löschke on March 29, 2012 at 5:12am

Some of the Rhino and/or GH functions may use single precision floats values. Those have 6 to 9 significant decimals. So anything with more decimals may be rounded off at some place.

Visual precision of the slider is nowhere near 2 decimals. So as an input gadget, already 6 digits are way overkill.

If you need to adjust values from lets say 0 to 0.00001, you can have a slider change from 0 to 1 and divide the output by 100000.

Permalink Reply by Yannis on March 29, 2012 at 6:20am

Hi Hannes,

Thanks for the reply. As far as my understanding goes, the values that are exchanged between components are of at least 15 significant decimal digits, essentially double precision values. I have tested this with the C# component , and I would suppose that all recent components that take real numbers have such precision.

In the example below, the first component is producing the square root of the input, while the second one just outputs a copy of it's input. In both cases, both the numbers and their string values are output. This shows that components are actually using double precision for data exchange.

What you suggest about the visual part is not entirely true as in the case that you set a very small range, e.g. 0 to 1E-5, in which case values between the 1E-6 steps are indeed obtainable by manipulation of the slider head, and you can see that the slider takes discrete values. And then of course there is the possibility of setting the value of the slider by typing or programmatically.

Of course dividing is a solution to that, but I would say that it is rather cumbersome and a possible source of errors in complex definitions, therefore I am asking for a possible alternative.

Thanks again for the reply.

Yannis

Permalink Reply by Hannes Löschke on March 29, 2012 at 7:04am

Hey Yannis,

your're right, GH keeps numeric values at best possible resolution. There are hidden cases of round off. While GH will convert everything to double precision, the native vertex coordinates you will get from a Rhino mesh are Point3f (the single precision twin of Point3d).

Most GH geometry components route through to Rhino, which works on tolerance settings. Reading the RhinoFAQ on tolerances also shows that more than 6 significant digits aren't  reccomended. Operations with values close to or below tolerance are likely to fail.

So it is good practise to keep a max of 6 significant digits.

btw. having a slider change from 1E-5 to 1E-6 is basically having a slider vary from 1 to 10 an dividing by 1E-5. So visual precision is still around 2 digits.

Permalink Reply by Yannis on April 4, 2012 at 5:44am

Hi Hannes,

Thanks for the reply and sorry for the my delayed one, 

Thanks for the FAQ link also...it does shed some light in the specifics of Rhino regarding numerical precision.

To overcome the precision issue, I ended up coding a "slider" of my own, which is in the making currently, and as it seems it works fine outputting double precision values :)

In any case, just to demonstrate the visual "limits" of the grasshopper slider I have attached a file with a default slider from 0 to 1E-5, where the discrete values are visible.

Thanks,

Yannis

Attachments:

• Slider.gh, 1 KB

Permalink Reply by David Rutten on April 4, 2012 at 9:31am

Sorry, no. 6 digits is a hardcoded limitation. I realize this makes it difficult to have slider that go from 0.000000 to 0.000001, but it's just the way it is for now. You can use the Digit Scroller if you want more decimal places though.

ps. Reason for 6 digits btw is because I felt that numbers with lots of digits are difficult to read. So instead of having a slider from 0.000001 to 0.000002, I'd much rather the slider goes from 1 to 2 with an expression behind it to adjust the numeric domain.

--

David Rutten

david@mcneel.com

Poprad, Slovakia