My input is 0 but the equality component disagrees. Is this a bug or am I missing something?

Try `Smaller` instead, using an arbitrary, very small value like 0.0001 on the ‘B’ input. And use `Abs` (Absolute value) on the ‘A’ input to handle negative values; this can be done using the expression “abs(x)” directly on the ‘A’ input. Like this:

Yep, this will do the trick. Happened to me few days ago and this is exactly how I made my def working. But why does it happen in a first place?

Probably one of the most asked gh questions (and programming in general)

https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

Interesting read. I have noticed that the values weren’t exactly rounded.

So when exactly Equality component can be used if every reading has some tolerance applied?

Many thanks for the help, that works perfectly. Michael, it might take a few weeks for me to get to the bottom of that!

It’s not just zero, of course. The same technique applies to any value you want to match. If the difference is smaller than 0.0001, it’s a match!

Equality does exactly what it says. Tests if things are equal. Like very basically exactly equal. For instance if you have two numbers: 0.000000000000000001 and 0.000000000000000002. Grasshopper displays them to their set decimal. So it will display as 0.00 depending on your settings. But this does not mean the number is 0.00 - that is again just the decimal level you are displaying. Equality however is checking the real number and as you can see 0.000000000000000001 and 0.000000000000000002 are technically not the same.

You can change the decimal display in Grasshopper’s File>Preferences.

Yeah, I know this settings. yet slider is set to 6 digits max or i miss some settings?

When you are comparing integers for example, no accuracy problems there. Or maybe if you first specifically round your floating point values to a small number of decimal places.

Maybe, but if comparing sliders it shouldn’t matter, sliders make the number they say they do. The issue is with values generated in other ways (area, lengths, ect.)

If I am not mistaken I recall reading somewhere that @DavidRutten is adding these tolerance tests to the future similarity component (which test currently only by percentage)

Well I’m not (Have it in Pufferfish ) but I am sure it will be a more than welcome addition to native GH - based on how many times this question is asked haha

Yeah agreed. It’s totally unclear what the 10% refers to. Must value B be within the \left [ 0.9A, 1.1A\right ] range? Or is the ten percent measured from B? Or whichever value is bigger?

There’s only really two meaningful similarity metrics for floating point values that I can see; absolute difference and discrete distance.

Everyone will be familiar with the former and it’s what almost every software uses, the latter measures the amount of unique values in between the numbers. It means that small numbers have to be more alike than big numbers for them to be considered similar. This metric more closely tracks the actual inaccuracies that occur in floating point operations.

Hi David, thanks for the clarification

I can see why this wouldn’t work for A=0

I guess that if B=0, then the tool should automatically switch to an “Absolute” difference, which is how I understant Pufferfish does it.

In the other cases, it could work using the following logic :

Let’s assume target value “B” is 3.2

If A is smaller than 3.2, then (B/A)*100 is computed as the **“percentage of similarity”** ; 100% is reached when A=B

If A is bigger than 3.2, then (A/B)*100 is computed instead.

If A and B don’t have the same sign, the option would switch to “Absolute” difference.

Would that make sense ?