2016-08-19 12:25 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at 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?
> 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
>
> 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 at hpi.de>:
>
>> Hi, there.
>>
>> Right now, this is can happen when comparing two points:
>>
>> (100 at 50) < (100 at 60). "false"
>> (100 at 50) > (100 at 60). "false"
>> (100 at 50) = (100 at 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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160819/b9659a08/attachment.htm