Strange behavior of Smaller Than component

I noticed a malfunctioning of the Smaller Than component. If I use the Equality component I get the same error. What can be wrong?
Thank you.


Ciao Francesco!

have a look at these discussions:


Giulio Piacentino
for Robert McNeel & Associates

Thank you Giulio,
I was starting to think something like that could be the problem.
Is there a proper way to tell Grasshopper that a number that “look” in a certain way is in that way?
I think rounding the number to few decimals should work, what you think?
I used this trick for the moment and it works. Actually the Number component here is not necessary, but
I realized that not all the inputs read a text as a number so just to be sure.


You can change the formatting of UI numbers in Grasshopper to some degree in the Preferences. However there are good reasons you don’t want to always see 10 decimal places. It makes numbers almost unreadable. The display rounding is supposed to show you the likely intent of the number, rather than its actual value.

If you want to see the actual value of a number, you’re better off using a custom format mask. Either using the Format component or an expression:

Thank you David for the additional explanation. Although in this case I want the opposite, that two numbers like 4.5000000000008 and 4.5000000000009 are considered like the same number by Grasshopper, so I used a simple rounding at the fourth decimal and it works .

1 Like

In Pufferfish
I made a component “Equality within Tolerance” for this reason. Check it out if interested.

1 Like

Michael, thank you for the reply and the suggestion. In GH there is already a Similarity component that works with a tolerance (that I could have used but then I would have needed an increased number of components) is it something similar? Anyway in this case would have been perfect a “Smaller Than within Tolerance”.

Similarity uses a percent factor. My component uses the actual tolerance value you want to test within. To me it just makes more sense (usually have it set to .001)

Michael I understand. Interesting. Thank you again.

Sure here you can see it (wasn’t at a computer before) as well as native Gh way to test. The way you test is if the absolute value of A-B is smaller than tolerance it is true. (11.3 KB)

Very interesting and useful indeed. Congratulation for your work Michael.

@DavidRutten I think that it would be an option to have GH2 show an error tolerance beside numbers when they are rather close to the shown figure, but not exactly so. It would raise the question at least…

Something like:

10.5 ( -2*10^{12})
10.5 “alone”

This would make numbers readable and also rather more precise…

Agreed, also panels should display numbers more informatively. (see this).

I imagine number (and point/vector/colour/plane/…) equality should support both relative and absolute tolerances, as well as discrete tolerances. So you can test for equality with a tolerance of 2.5\cdot 10^{-4}, or 1\%, or if there are fewer than 100 unique values between the two operands.

1 Like

Thank you Giulio and David for the comments and information. Yes more informative panels would be a great thing. David, like the example from your link. I admit me to I use the output of the panel to continue the data (when needed reconverting the text into numbers with the Number component) because, like many other probably, I have the need to “see things while they happen” to have a better control/inspection over the algorithm above all when they get very large and complicated. Would be great also to have a preview of the output of the geometries up to a specific output without the need to see Rhino viewport, as you show in the example.
I know this is not the place but I take the advantage of the discussion about panels to say another very handy feature would be that to scroll the data tree while the mouse pointer is inside the panel (with the mouse wheel) whereas the same action make you zoom in and out when the mouse pointer is just on the canvas.