Grasshopper

algorithmic modeling for Rhino

for some reason, the "larger than" component gives the right answer only if the float numbers resulted from the upper distance component are passed through a panel ... gh file attached

thank you for your attention!

Views: 674

Attachments:

Replies to This Discussion

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}

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!

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.

ok, thank you, good to know!

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)

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service