Units and Precision?

Replies to This Discussion

Permalink Reply by Giulio Piacentino on May 3, 2010 at 3:49am

Hi Chris,

the random number generator returns pseudo-random numbers which have (generally) many decimal digits.
The panel and the preview, though, do not show by default all figures after the point, but these digits should still be taken into account if you use the result directly inside any component that expects floating point numbers (doubles).

Here an example:

I hope it helps,

- Giulio

Permalink Reply by Chris on May 3, 2010 at 10:50am

OH right so it does go through..

i finally managed to get the model to work in mm units which is much more precise giving me 3 more digits, but i didnt realise that

thanks Giulio grazie mille

Permalink Reply by Justin Diles on February 3, 2013 at 2:03pm

Hi Giulio:

I am following your formatting exactly, but get an error. Does the Evaluate component still work the same way in the latest version of Grasshopper?

Thanks! Justin

Permalink Reply by David Rutten on February 3, 2013 at 3:00pm

Yes, formatting has never changed as it works in the same way as standard .NET formatting.

Formatting rules are somewhat obscure but they are consistent and quite flexible. Basically your formatting string may contain any number of curly bracket pairs with non-negative integers in them:

"When {0} brings back {1} days and {2}"

The number inside the brackets refers to the data to insert in that location. In effect, {x} is a placeholder for actual data. The data inserted into a specific bracket pair is the data supplied in the latter part of the function. {0} refers to the first item, {1} to the second, {2} to the third and so on ad infinitum.

If I supply some data the entire expression may look like this:

Format("When {0} brings back {1} days and {2}", "Spring", "blue", "fair")

which will result in the string "When Spring brings back blue days and fair".

If the data you're inserting is a number (or a date) then you have additional formatting flags that you can use. These additional flags appear behind the placeholder index integer separated by a colon.

Format("Pi = {0:0.00}  ({0:0.000000})", Pi)

The :0.00 means the number will be formatted using two digits. The other flag will enforce six digits, resulting in: "Pi = 3.14  (3.141593)"

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Justin Diles on February 3, 2013 at 3:28pm

Thanks David.  I think I've got it. Unfortunately, this does not solve my real problem since the Orient (Change Basis Transformation) component seems to subtly change the length of objects.  No matter how accurately I view the floating point numbers, the lengths of reoriented objects don't match their parent objects. Practically speaking, thi means that when I compare the lengths of oriented and unoriented objects in order to make corresponding labels, the wrong objects get referenced.  (it isn't the best system anyway but it's the one I could think of...)

Permalink Reply by Hannes Löschke on February 3, 2013 at 3:41pm

Any floating point operation is limited to the precision of double floating numbers (a bit more than 15 significant figures). So any math operation will produce inaccuracies.

In order to compare two floating point values, you should calculate the difference and check against a given (document-)tolerance.

@David: since this seems to pop up quite often, what about a "compare with tolerence" component?

Permalink Reply by David Rutten on February 3, 2013 at 3:46pm

Similarity sort of does this, but with a relative tolerance rather than an absolute one.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Hannes Löschke on February 3, 2013 at 6:32pm

Ok, but what about the math components?

I mean, most cases people actually need the equality component for numbers they don't want to compare numbers to the last significant digit. It just happens to work sometimes and if not, people end up asking about tolerance issues.

What would be the possible harm in implementing float equality "the right way"? Maybe with an option to deactivate document tolerance settings. Speed doesn't seem to be a valid argument when a single-cycle operation is encapsulated in a GH-component. ;)

Permalink Reply by David Rutten on February 4, 2013 at 4:51am

The problem isn't speed, it's predictability. I can set an arbitrary tolerance for floating point comparisons but there will always be people with even less accurate numbers or people who have more accurate numbers and require that significance to be part of a comparison.

Floating point numbers will always have tolerance issues and it's not possible to write a smart comparison algorithm that will always tell you whether two numbers are identical within the implied tolerance.

I could replace the inequality output of the [Equality] component to be a Similarity output that performs fuzzy equality, but there will always be border cases and it will be much harder to explain the behaviour of the components when they are so 'smart' to begin with.

One question about fuzzy comparisons, should it be up to 6 or 8 or 10 decimal places in decimal notation or scientific notation? I.e. is 0.999998 the same as 1.000001? If yes, is 0.000001 the same as 0.000002? The difference between the first two numbers is 0.0003% but the second pair differs by 100%.

What about 1000000 and 1000010? They only differ by 0.001%

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Hannes Löschke on February 4, 2013 at 8:10am

I see you point but let me play devil's advocate here.

GH isn't MATLAB, it's a tool to manipulate Rhino geometry. All Rhino geometry is bound to the document tolerance. No numeric value should be expected to have more precision than quaranteed by the tolerance setting. So one way or the other errors due to Rhino operations will creep in.

Most users will have a Rhino background, some may know their way around math but only very few will know about the problems and limitations of digital floats. They expect their curves to be the same length before and after the are rotated. They expect the equality component to just work.

In Rhino, if an operation on very small geometry fails, it's common sense to just allow for a few more digits of tolerance. Already there are some GH operations that work or fail depending on document tolerance.

Very large numbers are bad in Rhino because they mean the geometry is far from origin or a bad choice of units. Both to be avoided according to Rhino doctrine.

So very large numbers and numbers far below tolerance are bad In Rhino. I don't see any reason they shouldn't be bad in GH. At least for comparison.

Comparing the relative difference of 0.999998 and 1.000001 to 0.000001 and 0.000002 is a moot point, since both deviate below any reasonable Rhino tolerance. Both cases should be equal. As for 1000000 and 1000010, since both numbers deviate above reasonable tolerance the are not equal.

Permalink Reply by David Rutten on February 4, 2013 at 10:13am

Numbers are not always related to distances, whereas the Rhino tolerance settings are. You could have two points that are further apart than a tolerance of 0.01 units, however when you project them onto a curve the difference between their projection parameters may well be less than 0.01.

I think it makes sense to add another output to Equality that compares maybe 12 decimal places instead of all 16 and call it "Implied equality" or something, but sooner or later people will run into floating point problems and I'd hate to be in a position where I have to explain the Grasshopper 'smart equality' algorithm before I can explain why two numbers really aren't equal.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Justin Diles on February 3, 2013 at 8:47pm

David:

Please take a look at the attached file if you have the chance. The edge lengths of the Reoriented Mesh have been rounded or are distorted from the original. I know that it is very slight, but I am trying to match shared edges  in a larger, exploded mesh by length (to label them for fabrication). I think greater precision would allow me to this correctly. Can I get values that match between the original mesh and re-oriented mesh?!  Many thanks!

Justin

Attachments:

• ReOrient_Tolerance_Bug.gh, 5 KB