Error in Equals module

Replies to This Discussion

Permalink Reply by Hyungsoo Kim on August 30, 2017 at 8:32am

Actually it's not a bug. Check attachment and visit here.

Attachments:

• BuginEquals_re.gh, 26 KB

Permalink Reply by Bas Goris on August 31, 2017 at 3:17am

Thanks!

But why? Is it an idea to take over (as default) the tolerance settings of Rhino?

Permalink Reply by David Rutten on August 31, 2017 at 5:08am

But why?

Just standard digital arithmetic inaccuracies. Nothing you can do about it unless you can switch to integral numbers or symbolic solver.

Is it an idea to take over (as default) the tolerance settings of Rhino?

No. Rhino tolerances have a very specific geometric meaning. Here we are dealing with generic maths and the tolerances involved are specific to each case.

If you want to compare two decimal numbers, you have to measure the distance between them and then figure out whether that distance is acceptable to your current case. You can use the Similarity component sometimes, but other times you just need to be specific about it.

Note that a common fallback is to round the numbers to N decimal places, but this can cause mistakes. For example, assume you want numbers to be equal to within one part in ten-thousand, so you round them both to 4 decimal places. But it could be that the numbers fall juuuust on opposite sides of the rounding threshold, in which case you'd amplify the difference between them.

Permalink Reply by David Rutten on August 31, 2017 at 5:12am

And by the way if you think it's bad enough that you have to pick a tolerance for each comparison, it can be a really complicated problem. A specific calculation doesn't just have a certain fixed amount of inaccuracy, the inaccuracies differ based on the magnitude of the numbers involved. You can have many calculations all involving small numbers, and the sum-total tolerance can still be tiny, but perform just one calculation on large numbers, and the absolute difference between two big numbers that ought to have been the same can in fact be enormous.

It's complicated, it's messy, and very few people really understand binary floating point arithmetic well enough to make informed decisions.

Permalink Reply by Bas Goris on August 31, 2017 at 5:36am

Hi David,

Your explanation is clear enough for a guy who does not understand binary floating point arithmetic. Despite it is complicated, it does not belong (to my opinion) to an easy program method like Grasshopper. For my use, a default tolerance of 0.001 units or even 0.1 units will do. What about a input parameter for the tolerance, with a default setting depending on the Rhino tolerances?

Cheers

Permalink Reply by David Rutten on August 31, 2017 at 11:24am

What about a input parameter for the tolerance [...]

That's basically what [Similar] is. I don't understand floating point arithmetic well enough either btw., and picking a default will too easily result in different numbers being treated the same without the user spotting it, causing potentially very expensive problems. Better to fail loudly at it than to do something unexpected quietly.