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.

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.

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.

@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.

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.