List Contains Doesn't give the right answer

In the script we need to check the missing elements in specific Z point location
I am using List contain but it doesn’t give the right bool list


I tried another workflow using == as you see in the picture too, but it is taking too much time as I have thousands of elements

can you check the dicimals: -5,4000 == -5.39999
You are using round

1 Like

This is a very strange thing where it seems that the number -5.4 doesn’t work.

-5.4 First Number

-5.4 as Second Number

Both -5.1 work, but the -5.4 does not

As @Draxl_Andreas pointed out, it’s an internal rounding issue. If you round the final values of the second (already rounded) list to 2 or more places it will work.

4 Likes

4 Likes

Often I turn numbers to strings when comparing due to the rounding issue.

Alternatively you could use the almost equal node and the anytrue node at sublist level which were added in 2021 onwards i think.

4 Likes

The weird part for me is that all but one of the values rounded correctly and equaled out, but just that one didn’t. The strange ghosts persist.

1 Like

I tried that but doesn’t work … only works when I used Math.Round as mentioned above

you are right

That was frustrating, so thank you so much and thanks @SeanP too.

If you look at the original image you can see that there are a few values that don’t round correctly. It’s actually all the values that are divisible by 3 after dividing by 0.3. This is why I think it’s a rounding issue. If Dynamo is using 0.3333 instead of 1/3 it could cause a negligible but non-zero difference in rounding when multiplying back.

Might be worth looking into more.

I did however notice that everything was equal if I used the == node. So it could be a difference of how Dynamo handles different object types if List.Contains doesn’t use the same comparison as a mathematical equivalent.

EDIT: Seems like this might be true.


@solamour @Michael_Kirschner2 Any ideas?

3 Likes

Yes. The disparity between contains and == is what threw me from thinking it was a rounding issue because I assume the equality mechanism would be the same, but as you show and I previously showed, the comparisons are not the same.

@Aparajit_Pratap any thoughts here on why these two functions return different values? Assuming we have different tolerances?

@solamour the List.Contains node tests for containment of any type of object in an arbitrary list of object types so the comparison is generic object equality and not a number equality per se. In @Nick_Boyts’s graph, performing a division converts the integers to doubles so now the List.Contains node is doing a comparison between integers from the original list and doubles and therefore returns false. If it were a number equality test, it would return true as expected as does the Equals node. We should probably handle the case of number containment (equality comparison) as a specific case in the Contains node.

3 Likes

That makes sense as to how the List.Contains node works, however, if you look at the image in the initial post, the original list is already doubles and some of them do return true.

2 Likes

@Nick_Boyts, agree this case was strange! So @Aparajit_Pratap has added in a special case to deal with numbers in this PR :slight_smile: Add special case for number containment test to List.Contains by aparajit-pratap · Pull Request #12672 · DynamoDS/Dynamo · GitHub

2 Likes