Failed to pick up items from a list with the same value then translate them back into their relative position

Grasshopper
,
1

Hi all mighty grasshopper gods,

I’ve encountered a problem, where I have a list of points crusted in a grid, and that I’ve randomly extruded into different length. What I’m trying to do is to pick up the pieces with a certain length, say 150, in their relative position.

I have created a = equality command to filter out the value of 150, and cull pattern it to the list of all point in order to pick up their exact location.

However, I’ve checked with the model and found that they don’t match up… Can anyone help me explain why this happened?

Thanks!

2

There may be gods here, but even they can’t see into your brain. Please provide a file.

1 Like
3

Thanks again Ethan :slight_smile:
I eventually figure it out maybe it was because of the list of points I got didn’t match the list of length in the correct order. Because it was a merged set of data and I reckon somehow that’s the reason. What I did was to pick them up from the different data sets individually, which was a bit pain, but did get me the result I wanted… I will try to clean up the file this week and maybe upload the whole thing up so that you can have a look and see how it could have been organised or simplified. Cheers!

4

Equality is a dangerous component to use. If you are comparing decimal numbers, equality will only work if the numbers are really the same. However they could easily be 150.0000000000002 or 149.9999999999997.

5

@DavidRutten Are you still considering having a built-in option with rounding into the comparison components? As discussed here:

6

Yes, GH2 will provide two basic equality tests for values involving floating point numbers.

  • Absolute difference: that is, two values are considered equal if |a-b| \leq t for any user specified tolerance t.
  • Discrete difference: that is, two values are considered equal if the number of possible in-between values is equal to or less than some user specified distance k.

The former approach is basically what Rhino uses when it’s dealing with tolerances. It’s reasonably intuitive and straightforward, however it suffers from poor interplay with the non-linear nature of floating point values. The latter approach tries to formulate a equality metric which tracks the nature of floating point numbers.

Case in point, 64-bit floats can represent numeric values up to roughly 1.8 \cdot 10^{308}, or 179,769,313,486,232,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,000* if you insist on writing numbers like my girlfriend.

However there are an equal number of distinct values between zero and one as there are between one and this upper limit. Which is to say; close to zero consecutive values are packed extremely close together, while at the upper limit consecutive values have extremely large gaps between them. Gaps big enough to fit entire universes in.

And yet despite this enormous range in magnitude, all numbers have about 16 decimal places of accuracy. So when you perform a calculation on very large numbers vs. the same calculation on small numbers, the number of garbage digits you end up with is the same, but that inaccuracy manifests as a much larger absolute error for large numbers.

It is very difficult to predict what particular value of k is a good choice for a specific equality test, but with some experimenting I think good values can be chosen which will then scale correctly up to whatever the magnitude of the numbers involved happens to be.

\* (this is a representation of the base-10 approximation of the maximum value. The real value doesn't end with lots of zeroes when written in base-10, but I felt that would just make it harder to read/comprehend.)
2 Likes
7

ps. note that in the case of integers rather than floating point values, these two cases reduce to the exact same behaviour.

8

loved your explanation on the differences, and good to learn the fact about your gf’s preference with numbers :stuck_out_tongue: