------ 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's nothing wrong with the implementation and documentation. True, an erronous implementation of < 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 < t; 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 < 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 class mail_quote">On 4/1/07, <b class mail_sendername">David Flanagan</b> <<a href ailto:david / davidflanagan.com">david / davidflanagan.com</a>> wrote:</span><blockquote class mail_quote" style order-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 < t; operators all do appear to<br>strictly return -1, 0, or +1. That is, they don't simply return y-x to<br>compute a value less than, equal to, or greater than zero. 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 < t;<br>operators.<br><br>Anyway, I should say that it was probably presumptuous of me to assume <br>that the documentation is incorrect. Everything I've seen in writing<br>says that < t; must return -1,0, or +1. 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 < t; in the ruby-talk archives...<br><br></blockquote></div><br clear ll"><br>-- <br>"Life is unfair... but beautiful."<br>Scarlette Krimson ------ art_11202_15476906.1175426151852--