Hi, there.
Right now, this is can happen when comparing two points:
(100@50) < (100@60). "false" (100@50) > (100@60). "false" (100@50) = (100@60). "false"
This is because one component is the same and implementation in Point is like this:
< anotherPoint ^x < aPoint x and: [y < aPoint y]
Hence, points do not have like magnitudes. For the aformentioned examples, a "fix" could be:
< anotherPoint ^(self >= anotherPoint) not
Now, the interesting thing is that event handling (mouse clicks etc.) becomes awkward after that. :-D
Best, Marcel
-- View this message in context: http://forum.world.st/Could-a-Point-behave-like-a-Magnitude-tp4911882.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
Magnitude presume that < is a total order relationship https://en.wikipedia.org/wiki/Total_order
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
2016-08-19 10:44 GMT+02:00 marcel.taeumel Marcel.Taeumel@hpi.de:
Hi, there.
Right now, this is can happen when comparing two points:
(100@50) < (100@60). "false" (100@50) > (100@60). "false" (100@50) = (100@60). "false"
This is because one component is the same and implementation in Point is like this:
< anotherPoint ^x < aPoint x and: [y < aPoint y]
Hence, points do not have like magnitudes. For the aformentioned examples, a "fix" could be:
< anotherPoint ^(self >= anotherPoint) not
Now, the interesting thing is that event handling (mouse clicks etc.) becomes awkward after that. :-D
Best, Marcel
-- View this message in context: http://forum.world.st/Could-a- Point-behave-like-a-Magnitude-tp4911882.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
2016-08-19 12:25 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Magnitude presume that < is a total order relationship https://en.wikipedia.org/wiki/Total_order
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?
- there's no natural definition of <=
- 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
From a more formal POV, it's https://en.wikipedia.org/wiki/Ordered_field
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
2016-08-19 10:44 GMT+02:00 marcel.taeumel Marcel.Taeumel@hpi.de:
Hi, there.
Right now, this is can happen when comparing two points:
(100@50) < (100@60). "false" (100@50) > (100@60). "false" (100@50) = (100@60). "false"
This is because one component is the same and implementation in Point is like this:
< anotherPoint ^x < aPoint x and: [y < aPoint y]
Hence, points do not have like magnitudes. For the aformentioned examples, a "fix" could be:
< anotherPoint ^(self >= anotherPoint) not
Now, the interesting thing is that event handling (mouse clicks etc.) becomes awkward after that. :-D
Best, Marcel
-- View this message in context: http://forum.world.st/Could-a- Point-behave-like-a-Magnitude-tp4911882.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
squeak-dev@lists.squeakfoundation.org