Why doesn't equality work as I think it should?

When numbers are displayed on the screen, they are typically rounded to avoid looking like 31.5000000000000089, 31.500000000000000092 or 31.49999999999999997. In all of these cases what you see is 31.5, even though they are all clearly different numbers.

Almost all decimal numbers that are the result of some sort of mathematics (and often also ones that have been constructed by hand) suffer from noise in the least significant digits. Although this noise is in all likelihood meaningless garbage, it will still affect sort order as the smaller than and larger than operations are well defined. It also means that two numbers that look the same but are nevertheless different in the 12th decimal place, will not be treated as equal.

If you want to compare decimal numbers for equality, you almost always have to find the absolute difference between them and compare that to some tolerance threshold. For example;

Abs(A-B) < 1e-10

will evaluate as true if A and B are identical to within 0.0000000001. What tolerance to use depends on the numbers in question. If they are very big, you'll need a larger tolerance. If they are the result of many calculations, you'll also need a larger tolerance.

This description comes from http://www.grasshopper3d.com/forum/topics/sort-points-error-1

You can find the same question and similar (more or less descriptive) answers here :

http://www.grasshopper3d.com/forum/topics/equality-in-function-does...

http://www.grasshopper3d.com/forum/topics/equality-component-bug

http://www.grasshopper3d.com/profiles/blogs/equality-component-does...

http://www.grasshopper3d.com/forum/topics/equality-mistery-help

Replies to This Discussion

Permalink Reply by David Rutten on December 4, 2014 at 12:59pm

As an elaboration on the above, I present the following real case:

A sphere centred at (0,0,0) with a radius of 10.0 is intersected with a line.
The distance between (0,0,0) and the intersection point is calculated.
This distance is compared to the ideal value of 10.0.

Although 0.0 and 10.0 can both be represented exactly using floating point numbers, and although the answer to the above question is obviously exactly 10.0, we nevertheless get a distance that is slightly off:

By using the formatting pattern {0:R} we can see the number without any rounding, and it turns out to be 10.000000000000004 instead of 10.0. In fact there are two other floating point numbers in between the answer we got and the ideal answer, so we're not even a single step off, but three.

(The VB component uses floating point precision methods available via the MathNet package, which is why I shan't share the file.)

RSS