"Larger Than" bug

Replies to This Discussion

Permalink Reply by David Rutten on February 22, 2015 at 2:49pm

That's because a panel rounds all numbers to 6 decimal places. They then get converted back to actual numbers. The numbers themselves have far more decimals, and clearly they differ in the last few. You can use a Format component to see the actual values. The format you need is {0:R}

Permalink Reply by Andrei Raducanu on February 22, 2015 at 2:58pm

Hi, David, Thanks for the info! i was actually thinking that might happen, but i thought that hovering the mouse above the output hook would give me the full numbers, that's why i thought my supposition might be wrong. This shouldn't really happen, since i am just extracting the end point of equal-length parallel line segments, but it probably has to do with tolerances (a similar dilemma i encountered a while ago about points, where i had to use the similarity component instead of the equality one on apparently overlapping points)

Thank You for your feedback!

Permalink Reply by David Rutten on February 22, 2015 at 3:31pm

Floating point numbers simply cannot be trusted in computers. Put them through any kind of mathematical operation and you end up with garbage in the least significant digits. That's why I always round numbers before showing them on-screen, because if I didn't, pretty much all numbers would look terrible.

Permalink Reply by Andrei Raducanu on February 22, 2015 at 3:39pm

ok, thank you, good to know!

Permalink Reply by Arend on February 22, 2015 at 5:28pm

Is there any chance for a component that allows for checking if a value is equal within a certain tolerance? (Adding an option to the approximate function to choose and "absolute" mode?). (Similar to the RhinoMath.EpsilionEquals method)