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:
1 Like
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
1 Like
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!
1 Like
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.
1 Like
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.
1 Like
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
1 Like
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 ?