------art_11202_15476906.1175426151852
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think there's nothing wrong with the implementation and documentation.
True, an erronous implementation of <will still work if this is the
implementation, but if we use exact comparisons such as -1, trichotomy
might be broken. For example, if two comparable objects of the same class,
say a and b, are compared, and a is neither less than, equal, nor greater
than b, then what is the relationship of a to b? This will give us a hint
that the implementation of <is incorrect, and that's good, but I believe
it's better (and safer) to have a fallback. If we throw an error that
results from <returning a value other than -1, 0, and 1, then it might
have an impact to efficiency especially in sorting huge array of values
because we added an overhead of checking if the value returned is correct.

On 4/1/07, David Flanagan <david / davidflanagan.com> wrote:
>
> Replying to my own post...
>
> Let me add that the existing numeric <operators all do appear to
> strictly return -1, 0, or +1.  That is, they don't simply return y-x to
> compute a value less than, equal to, or greater than zero.  This would
> argue that the current documentation of Comparable is correct, but that
> the implementation is written so that it works even for broken <> operators.
>
> Anyway, I should say that it was probably presumptuous of me to assume
> that the documentation is incorrect.  Everything I've seen in writing
> says that <must return -1,0, or +1.  The implementation in compar.c
> makes it appear that this is not the case, however. I was not able to
> find any discussion of the return value of <in the ruby-talk
> archives...
>
>

-- 
"Life is unfair... but beautiful."
Scarlette Krimson

------art_11202_15476906.1175426151852
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I think there&#39;s nothing wrong with the implementation and
documentation. True, an erronous implementation of &lt;t; will still
work if this is the implementation, but if we use exact comparisons
such as -1, trichotomy might be broken. For example, if two
comparable objects of the same class, say a and b, are compared, and a
is neither less than, equal, nor greater than b, then what is the
relationship of a to b? This will give us a hint that the
implementation of &lt;t; is incorrect, and that&#39;s good, but I
believe it&#39;s better (and safer) to have a fallback. If we throw an
error that results from &lt;t; returning a value other than -1, 0,
and 1, then it might have an impact to efficiency especially in sorting
huge array of values because we added an overhead of checking if the
value returned is correct.<br><br><div><span classmail_quote">On 4/1/07, <b classmail_sendername">David Flanagan</b> &lt;<a hrefailto:david / davidflanagan.com">david / davidflanagan.com</a>&gt; wrote:</span><blockquote classmail_quote" styleorder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Replying to my own post...<br><br>Let me add that the existing numeric &lt;t; operators all do appear to<br>strictly return -1, 0, or +1.&nbsp;&nbsp;That is, they don&#39;t simply return y-x to<br>compute a value less than, equal to, or greater than zero.&nbsp;&nbsp;This would
<br>argue that the current documentation of Comparable is correct, but that<br>the implementation is written so that it works even for broken &lt;t;<br>operators.<br><br>Anyway, I should say that it was probably presumptuous of me to assume
<br>that the documentation is incorrect.&nbsp;&nbsp;Everything I&#39;ve seen in writing<br>says that &lt;t; must return -1,0, or +1.&nbsp;&nbsp;The implementation in compar.c<br>makes it appear that this is not the case, however. I was not able to
<br>find any discussion of the return value of &lt;t; in the ruby-talk archives...<br><br></blockquote></div><br clear
ll"><br>-- <br>&quot;Life is unfair... but beautiful.&quot;<br>Scarlette Krimson

------art_11202_15476906.1175426151852--