<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-08-19 12:25 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div>Magnitude presume that < is a total order relationship<br><a href="https://en.wikipedia.org/wiki/Total_order" target="_blank">https://en.wikipedia.org/wiki/<wbr>Total_order</a><br></div><br></div>For point, <= is not a total order.<br></div><div>It might be that neither a <= b nor b <= a<br></div><div>So Point is not a good candidate for Magnitude<br>(side note: we had enough problems with Float nan which is unordered!)</div><div><br></div><div>In short, why changing < is not a good idea?<br></div><div>1) there's no natural definition of <=<br></div><div>2) it breaks expectations<br></div><div><br></div><div>In longer form:<br><br></div>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...<br></div>But it's not a good idea because there is no natural relation order, an order that mix well with arithmetic like:<br></div><br></div>(a <= b and: [c <= d]) ==> ((a+c) <= (b+d))<br></div><div>Current definition of = has this property, but it's not total</div><div><br></div></div></div></div></div></div></blockquote><div>From a more formal POV, it's <a href="https://en.wikipedia.org/wiki/Ordered_field">https://en.wikipedia.org/wiki/Ordered_field</a><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div><div></div>Currently, I presume the usage in graphics are kind of testing if inside a bounding box with<br>p >= topLeft and: [p <= bottomRight]<br></div>So I'm not amazed that we can easily break things by modifying such basic method.<br><br>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.<br></div>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).<br></div>It should rarely be usefull, and is going to wicken detection of errors<br></div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2016-08-19 10:44 GMT+02:00 marcel.taeumel <span dir="ltr"><<a href="mailto:Marcel.Taeumel@hpi.de" target="_blank">Marcel.Taeumel@hpi.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi, there.<br>
<br>
Right now, this is can happen when comparing two points:<br>
<br>
(100@50) < (100@60). "false"<br>
(100@50) > (100@60). "false"<br>
(100@50) = (100@60). "false"<br>
<br>
This is because one component is the same and implementation in Point is<br>
like this:<br>
<br>
< anotherPoint<br>
^x < aPoint x and: [y < aPoint y]<br>
<br>
Hence, points do not have like magnitudes. For the aformentioned examples, a<br>
"fix" could be:<br>
<br>
< anotherPoint<br>
^(self >= anotherPoint) not<br>
<br>
Now, the interesting thing is that event handling (mouse clicks etc.)<br>
becomes awkward after that. :-D<br>
<br>
Best,<br>
Marcel<br>
<br>
<br>
<br>
<br>
<br>
<br>
--<br>
View this message in context: <a href="http://forum.world.st/Could-a-Point-behave-like-a-Magnitude-tp4911882.html" rel="noreferrer" target="_blank">http://forum.world.st/Could-a-<wbr>Point-behave-like-a-Magnitude-<wbr>tp4911882.html</a><br>
Sent from the Squeak - Dev mailing list archive at Nabble.com.<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>