In my opinion, Vector2 comparison functions have fairly non-sensical return values

[AtlaStar]

operators <, >, >=, and <= (in 3.x at least) first perform a comparison to see if x values are equal, and if so then compares y values if true or the x value if not. The issue is that in the event you have a vector2 with values [1, 300] and another with [2,3] the result of < would yield that the first vector is in fact 'less than' the second.

This is non-sensical, as vectors either represent a distance/point in space from an origin or alternatively a width and a height per the definition in the classes union. The first vector clearly has a further distance from the origin than the second vector, and if the vector is being used for its width and height information the area of the first vector is also significantly greater. The only reason it is considered less than is because unwarranted emphasis is placed on the value of x

The question I have is if there is more value in using the current equality operators or changing them to something which makes more logical sense. I do see that the implementation likely had sorting in mind (and only sorting, hence saying the return was fairly non-sensical) but the current relational operands seem to create a sort of 'gotcha' where the expected results don't match; a vector with values [1,300] is clearly not less than a vector with values [2,3]

The only challenge of changing what is returned, is simply that as width and height information appears to be coupled with a Vector2, a decision would need to be made as to whether comparing distances from an origin was more semantically correct than comparing the 'area' of them. I can see two.

The first is that the vector is treated like a vector; the relational operator returns based on distance from the origin regardless of whether it is being used to store width and height data with no other changes.

The second would be to decouple the width and height data from the vector; You make the vector act as the first choice, and introduce a type that properly acts as a rect rather than assigning a Vector2 for size info in the Rect2 class, and provide proper overloads for the relational operands.

One could also argue that a third choice exists; use the area like I said was possible above...and while that is possible I don't believe that to be even close to semantically correct in regards to what is expected when comparing two vectors, and because of that would make more sense if a proper rect class was used that was similar to some of the features of the current vector2 but with different overloads as mentioned above.

[theraot]

What Godot does is called lexicographic order, Godot is not alone on doing it this way, and yes it does not make sense for what you want. Once you have multidimensional numbers, you lose any concept of total order. You can define an ordering, but it is impossible to come up with one that will satisfy everybody's expectations.

So, let me show you some of the issues with basing comparison on the length:

• If you have two different vectors of the same length, they would not be one grater than the other, but they aren't equal either.
• If you have a non zero vector, it is always greater than the zero vector. Even if you subtract a vector greater than the zero vector from the zero vector, it results in a vector greater than the zero vector.
• Similarly, it is possible to find to vectors that are greater than the zero vector than when you add them together the result is the zero vector.

No implementation of these operators on vectors will make sense on every context. And be aware that if the definition changes, it would break code, so we need a way to provide the old behavior for those porting code. And here is the deal: you can get the length of the vectors and compare them (or compare length_squared to save one square root for performance), but we cannot reduce lexicographic to calling a function on the vectors to get a number and comparing the numbers. It has to be a comparison of vectors. And if there a way to compare the length of the vectors, why not use the comparison operators for lexicographic order?

Even if Godot changes the behavior of the comparison of vectors to be a comparison of the lengths, I'm going to suggest to write the code that you mean. If you want to compare lengths of vectors, then compare lengths of vectors , and if you want to compare areas of rectangles, then compare get_area of Rect2. It would also make for easier to read code. I remind you that you are going to read the code more times that you are going to write it (and there is autocomplete), and others might not know what these operators on vectors mean.

---

While I agree that a vector is not a size. Being able to create a Rect2 from two vectors makes sense to me. However, there are two alternatives: either you pass the two opposite points of the Rect2, or you pass one point of the Rect2 and the relative position of the opposite point respect to the first. That second case is close to what we have (except one might expect Godot to ensure the size to be positive, which you can get it with abs, but Godot does not do that), perhaps we can rename size to something more sensible?

I suppose we could add static methods on Rect2 for other ways to create them.

---

Do you want a function on vectors that gives you the area of the axis aligned bounding box defined between itself and the origin? I suppose that could be added if there is a use case for it. Although, I don't know what would be a good name for it. Yet, you can always define it on a helper class on your project if you need it.

[AtlaStar]

A lot of the issue imo is simply that the Variant type uses the lexicographic comparison of the Vector2 class. Looking at it from an end user standpoint and then comparing two gdscript vars that store a Vector2, the comparison not using the magnitude of the vector seems like a 'gotcha' as it deviates from the expected result; a vector of greater magnitude is greater than a vector with less magnitude or no magnitude.

More or less it seems wrong for the vector2 class to behave as if it were a 2 element array in terms of how values are compared, because the class itself is supposed to represent points in 2 dimensional space, and as such have an implied magnitude. End users themselves likely aren't (some probably are though) just using the class to store two unrelated values, but rather using them as what the name on the box says that it is; a Vector2. So this is a matter of fulfilling an end users expectations on the results of comparing two Vectors more than anything.

The matter with the Rect2 is really only a semantical one that doesn't affect end users...and changing it now would just be a breaking change without strong justification as the only benefit would be slightly making the Vector2 class simpler to maintain, but ruining portability of gdscript code written in previous versions of Godot.

[lentsius-bark]

As an end user who also started more seriously looking into coding (and godot) 3 years ago, I might be a rare case but this has never been an issue for me. It seemed logical and comparing vectors when necessary, in my path of learning, came with the understanding of what it is i am looking at to compare and finding the appropriate manner.

[fire-forge]

As others noted, the way it works is intentional. I found it weird too when I first learned this, but it's fine if it's documented well so people aren't left confused.

I use vector.length_squared() < value * value for comparing vectors.