Equal vectors

both Vector Z axis and at least the frist element of my list are identical vector data type:
Vector(X = 0.000, Y = 0.000, Z = 1.000, Length = 1.000)

YET, they do not trigger any True value for equality… ?

Hmmm the result is the same for X - Vector.ZAxis and Y - Vector.ZAxis…
Maybe you can try and check separated vector data:

X1 == X2 &&
Y1 == Y2 &&
Z1 == Z2 &&
L1 == L1

Which will find all equal vectors.

I would guess that it’s a rounding error, like 20 digits behind the comma. Try something like this before testing on equality:

@Gerrit_M never round vectors. You’ll lose precision.

Peculiar issue with == node

I’do what @Jan_Secnik suggested and decompose the data into it’s components and compare them instead.

@fluffyhugger I think it depends on what you’re trying to achieve. If you’re just aiming for the orientation like up, down, north, east, south or west I can’t see the problem of rounding the vectors. Or is there something that I am missing?

@Gerrit_M For orientation such as up/down/left/right/forward/backward is not the case. But other then that I’d still say never round vectors and angles for that matter. You’ll end up in a different place and you not gonna like it.

The reason and solution to your problem is explained here: What does this mean(==) plz...?


Best to use Vector.AlmostEqualTo when comparing vectors.


1 Like

Yeah… Vector.AlmostEqualTo works.

Yet another insane Dynamo quirk…

By the way, it cannot be a rounding error, since that is the flat face of a ceiling modeled horizontal, flat, Z straight down.

Also, both “==” AND “list.equals” return False, so i am not sure how the pointers versus objects thread is of any help: in there, “list.equals” worked as expected (returned “True”). In my case, nothing triggered a True…


Not sure I would call it a quirk, but perhaps a feature which you were unaware of? This is a common method in geometrical computation, but definitely one of those things you don’t know until you need it.

Rounding errors can and will happen to any data input. Sometimes the software platforms we use corrects inputs to account for them, sometimes not. In your case this isn’t likely partially due to the geometry conversion - that Revit surface is a different but of data than the one in Dynamo by definition - they have to be translated. So the normals which result are also different.

Once you start doing stuff computationally instead of UI driven (where 0.00000000001 degrees wouldn’t matter) you have to be a bit careful about data which has to be interpreted (anything which is imported). Math.Round will help in most cases, but not with vectors, hence the almost equal method.

1 Like

Check Vector.IsAmostEqualTo node.