Order of members in constraint declaration matters. Why?

[oslego]

According to the docs, the constraints are two-way. Yet the order in which members are declared seems to matter.

For example:

#logo[top] == #container[top] + 64;

yields a different result from

#container[top] + 64 == #logo[top];

The latter yields the expected layout, but it is far less readable and intuitive than the former.
I've seen this swapped order in examples in the docs as well. Why is this?

Live example:
http://codepen.io/oslego/pen/WvqKXq

[andering]

I can't explain you why, while i don't have deep understanding of
GSS algorithms. But i guess it has connection with how things are calculated,
because its still math with order.

GSS obviously don't know where is #container[top],
so if you add : #container[top] == ::window[top],
it will behave equally.

[qm3ster]

You'll notice that in the first case the #containter has top: -64px
This is caused by neither of the two elements having any vertical constraints to the reference frame. They are underqualified.
The order of operations indeed changes because it doesn't affect performance, considering you could write constructs like .a[top]-.b[top]=.b[bottom]-.c[top].
Finally, if you look even closer, you will see that the solution is actually correct, since the #container is not only presumably but physically at top: -64px, relative to the window, and #logo is top: 64px from it. Setting #logo[top] to be 0 in developer tools clearly indicates the effect.