On Fri, Oct 5, 2012 at 11:08 AM, Jean Niklas L'orange <jeann...@hypirion.com> wrote: > > > On Friday, October 5, 2012 2:39:05 AM UTC+2, Ben wrote: >> >> user> [(== 0 0.0) (== 0.0 0.0M) (== 0.0M 0)] >> [true true false] > > > When passing two arguments to ==, == will be transitive. > >> >> user> [(== 0 0.0 0.0M) (== 0 0.0M 0.0) (== 0.0 0 0.0M) (== 0.0 0.0M 0) >> (== 0.0M 0.0 0) (== 0.0M 0 0.0)] >> [true false false false true false] > > > This is more of a problem with number equality, not the transitivity of ==. > (== x1 x2 x3 ... xn) can be rewritten as (and (== x1 x2) (== x2 x3) ... (== > xn-1 xn)). > > So if you compare (== x y z), then if x = y, then the result of (== x z) and > (== y z) should be equivalent, considering the numbers are, well, numbers. > > I believe the issue lies within the bigdec-parsing, which seems to have two > zeroes: (== 0M 0.0M) returns false, and their hashcode (0 and 1, > respectively) are different.
Yea, I think this is the peculiar definition of BigDecimal.equals() biting us here. http://docs.oracle.com/javase/1.4.2/docs/api/java/math/BigDecimal.html # Note: care should be exercised if BigDecimals are to be used as keys in a # SortedMap or elements in a SortedSet, as BigDecimal's natural ordering is # inconsistent with equals. See Comparable, SortedMap or SortedSet for more # information. equals(): # Compares this BigDecimal with the specified Object for equality. Unlike # compareTo, this method considers two BigDecimals equal only if they are # equal in *value* and *scale* (thus 2.0 is not equal to 2.00 when compared by # this method) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
