|
|
For point, <= is not a total order. It might be that neither a <= b nor b <= a
So Point is not a good candidate for Magnitude
(side note: we had enough problems with Float nan which is unordered!)
In short, why changing < is not a good idea?
1) there's no natural definition of <=
2) it breaks expectations
In longer form:
We could define some total order (Matlab did it for complex), there are infinitely many possible definitions, like sort x first, then y, or radius first, then angle, etc... But it's not a good idea because there is no natural relation order, an order that mix well with arithmetic like: (a <= b and: [c <= d]) ==> ((a+c) <= (b+d)) Current definition of = has this property, but it's not total
Currently, I presume the usage in graphics are kind of testing if inside a bounding box with p >= topLeft and: [p <= bottomRight] So I'm not amazed that we can easily break things by modifying such basic method. In Matlab, defining < on complex has practically
no interest (except when there's small imaginary residuals), but
prevents programs to fail, delaying detection of errors. For me, the most suspicious decision is to authorize Point < Number or Number < Point, just because we can (or just because it's a side effect of authorizing Point+Number). It should rarely be usefull, and is going to wicken detection of errors
|
Locked
