This is not user friendly. At all. @DavidRutten
No new user would have guessed this in a million years. And even if he did, he would have no idea how to solve it, because rounding to x decimal places is not even a component!
The value is clearly CLEARLY 2.4400000000. I measured my line in Rhino.
Fix this please. I will not get my wasted time back, but at least it will save someone else’s time.
ROUND.gh (14.7 KB)
It is actually a very common programming thing not specific to Grasshopper. When using these operations you should always consider tolerance in double comparisons.
One way is via epsilon equals
Another way is making your equation something like abs(A-B)<tolerance
And the other is rounding like you did.
I feel ya. It has been brought up several times before, have a look at this topic where David shares some of his earlier thoughts, not sure if his opinion about it has changed:
In my opinion it should be “What you see is what you get”. If it shows a value of 2.44, it should be 2.44 and not 2.4400000001. If it’s not 2.44 it should either show the full number or have some symbol “~” indicating this is not precisely that number.
Ah. The devil binary form of numbers… 
My line is 2.440 to infinity. Guaranteed.
I mean, common sense here people. If you measure the line with maximum precision that Rhino can achieve and you still get 2.440, then the software somewhere has to say, "yup this is indeed 2.440. Make rounding internal to maximum precision. Simple.
Hi Micheal, I know that, thanks for the link.
Still, I thought the whole goal of making programming visual was to make it easier and more accessible. This is counterproductive to that goal. Most people that use GH have no idea about programming, why are you bringing up programming? The common user does not care about the why’s. Honestly I don’t care either.
My GH is set up to display the maximum amount of decimals. Yet, that panel says 2.44.
You deliver a shoe to a client, it fails, are you going to bring up chemistry and try to explain why the adhesive failed or why the rubber melted? He won’t care. He will say, this should be working, I paid for it to work. You would then probably say “Here, take another shoe”.
I have this rounding issue present when I am working, I always use smaller than 0.01, or document tolerance and almost never use Equality. But this is different.
What is the point of explicitly telling the software to do something that I am already assuming it is doing by what it is showing me? It is not like I assume out of thin air. That panels says 2.44!
Make GH do this automatically. Round values to document tolerance.
I mean it does not take a genius to see that most people that use GH will stumble upon this and fail to solve it. It just so obvious…
As a developer, how can you expect so much from your user?
That is not really advocating on part of the user. We are not protecting the user here. In the words of Bob Tabor himself:
You don’t want to leave your users feeling stupid, in the sense that they did something wrong, you want them to fill empowered and you want them to feel like your application is well built and it considered them whenever you were building it. Users expect a reliable experience with no surprises.
Most people that use GH have no idea about programming, why are you bringing up programming? The common user does not care about the why’s. Honestly I don’t care either.
That’s cool. I was just informing, I’m not against it.
My bad then, in my head it sounded more like “Yeah this is a common issue in computer science that is basically unavoidable due to the limitation of our technology, you should have known that, and in knowing that you would not have made the mistake of setting up your definition like this”.
I think going to doc tolerance is a nice idea. It could be a check box in preferences (set to on by default)
I am actually surprised this is not the case. I mean, it is already the case for 99% of GH native components. If you set your Rhino’s document tolerance to 1000, you will probably get intersections that are not real, or the Cull Duplicates component would probably cull points that are not equal.
Not coherent. How come I can compare points that are not equal as equal then? “Uuuh bending reality…forbidden”
What just happened? Did I actually bend reality here? Is this even legal? There is no way those lines actually intersect! Is McNeel legally allowed to lie to me or is it all relative?
I don’t know what moral compass programmers use, but making these lines intersect seems much worse than making 2.440000000000000000001 = 2.44.
Aren’t GH and Rhino friends? What’s up with all these individual decisions? Rhino can lie to my face by 1km and GH can’t even lie in the background by 0.00000000001
So these are the exact values of your line lengths:
Pretty much all numbers which are the result of a calculation have this very small noise in the least significant digits. Only number which you enter by hand, or which are the result of a rounding operation have ‘clean’ decimals.
This is a fundamental shortcoming of decimal numbers in finite digital computers. The only two solutions to this are:
Neither is ideal, but I opted for the latter. I do appreciate the fact that computers are really bad at maths is a shock for most people. It’s not really part of the general discourse surrounding software.
In GH2 I’m experimenting with ways to convey the disconnect between the values you see and the values you really have:
That’s wonderful David. That’s a much better solution than expecting the newcomer users to know about programming subjects like this one. It also also something that often lurks in the shadows so most people know nothing about it.
Aggressive in terms of the frequency of the rounding operation right? I think most of us would have no problem to always round using Rhino’s or GH’s maximum displayed decimal settings. Missing 0.00000000000000004 is not meaningful at all, and the way to check what is meaningful and what is not would be something like checking document’s tolerance or precision settings or number of decimal places displayed.
Well… it depends on when it’s done. Cumulative error from premature rounding could mess up a model.
But isn’t that what happens when you set up your tolerance settings? If you zoom in enough you will see your lines not actually touching. In this case, as it could not be any other way, it is the user’s responsibility to decide which is the optimal precision setting for what he is modelling. At least in this way he has a choice. Gh is offering no choice but to remain as precise as possible.
But in any case, I am much fonder of what David showed on his reply. If the panel would display this information, then there would be no need for rounding. It is like a coupled decision:
You either not round on the background but display full decimals somewhere for the user to be aware of it. Or make small specific rounding on the background, pretty much like many components already do looking at Rhino’s tolerance, and what you show on a panel is indeed the actual number.
The problem here is a decision was taken without its couple, in this case, display the full number or a visual clue that tells you that that number is exactly what you see like David or @siemen suggested.
Once you get used a bit, you won’t any longer even notice the problem, because you avoid it occurring from the start.
Back to your starting case, usually a fast solution I do is to work with absolute difference:
if(Abs(x-2.44)<0.0001, etc, etc) …
Sure, I also could have tested for 2.439 instead of 2.440.
If you opt for user education you better have an education program. Given the number of threads it would seem to me McNeel’s user education program is failing. Unless you expect the newcomer user to already know this…
Not quite sure, but it might be practical to limit the auto-rounding in comparision operators. (although quite harmful to performance)
Hi @DavidRutten can you explain to me why Member Index is working if the numbers are not exactly 2.44 ?
I believe Grasshopper has an internal epsilon of 1e-9 under limited circumstances. 
