Hi everyone,

I’m trying to filter out dimensions by a certain value but getting wrong results.

I try to filter out all dimensions that has a value equal or greater than 3500, but for some reason it’s not working properly. What could be wrong here?

Hi everyone,

I’m trying to filter out dimensions by a certain value but getting wrong results.

I try to filter out all dimensions that has a value equal or greater than 3500, but for some reason it’s not working properly. What could be wrong here?

UPDATE:

I just tried to use Math.Round node and it solved my problem.

It appears that the problem was dimension value that was a bit bigger than the value I tried to compare it to. The weird thing is that I entered my dimension value manually and I’m sure it was exactly 3500.0.

Does anyone can explain this weird behavior of dimension values?

Can you show the object type for the parameter? Wondering if this is a floating point thing.

1 Like

This is a result of floating point arithmetic not actually representing 3500 as we typically think of numbers in terms of a base 10 system; that is there are 10 possible values of significance at any digit. You can imagine we’d write down the numbers by hand, putting any one of the 9 values in any digit until we get the value 3500.

But computers don’t have that luxury as it’s too slow to convert between the values we see and the way they store information on disc and memory (binary format). So instead they typically use a 32 or 64 bits of data encoding, utilizing the IEE 754 standard (which unlike the many AEC standards is actually a standard, or at least closer to it). You may have seen applications referred to as 32 or 64 bit versions - this is what that refers to at a basic level.

As a result what we think of as a a simple number like 0.1 winds up having to be written as something like 0.1000000000000000055511151231257827021181583404541015625 under the hood. Similar issues occur with the base 10 number system which we use - ie: 1/3 is a more accurate representation than 0.33 because that 3 keeps going in decimal format. These rounding errors can pile up and cause discrepancies if we don’t manage them.

This is even further complicated in that the number you wrote down for the `y`

input may be a different type than the number from Revit in that one could be an integer while the other is a double, but that’s an issue I don’t really want to get into while on my travels back from BILT. The functional knowledge is FAR more important anyway.

As a result of all these rounding errors we as code authors have two options: We can force the values to be rounded to a desired precision prior to doing the comparison (effectively allowing checking that both values say 1/3 instead of one saying 1/3 and the other saying 0.333333…), we can do some math and see if the value is greater than our desired precision after subtracting the two.

The good news is that for equality checks the new ~= node in Dynamo 2.10 effectively does this for us, though I am not sure if the same applies for greater than or equal to.

1 Like

Wow! Thanks @jacob.small !

I would say it’s more than a wonderful explanation.

It makes more sense to me know. I should keep an eye on this next time when I try to compare numbers as this is not the first time when I get in trouble by doing so.

1 Like