You can also see the patch at this link, in case it is a while before JIRA is back up:
https://github.com/jafingerhut/clj-prescreen/blob/master/eval-results/2013-08-01/ticket-info/CLJ-1118-attachments/clj-1118-make-double-equals-true-for-more-bigdecimals-patch-v3.txt On Thu, Aug 1, 2013 at 10:16 PM, Andy Fingerhut <andy.finger...@gmail.com>wrote: > I agree, which is why I wrote a patch for the ticket > http://dev.clojure.org/jira/browse/CLJ-1118 > > (Depending on when you read this, dev.clojure.org may not be accessible > due to a recent DNS update made by the Clojure folks. Wait a while and try > again.) > > It makes not only the change you suggest, but also another one to how hash > is calculated for BigDecimal values, so that hash is still consistent with > =. Take a look at it and see if you think it is correct. > > Andy > > > On Thu, Aug 1, 2013 at 9:28 PM, CGAT <genovese...@gmail.com> wrote: > >> My understanding of == is that it is intended to establish numerical >> equivalence >> across types. But I think that basic contract fails with BigDecimal. >> For instance, >> >> (== 1M 1.0M) ; => false >> >> because the scale properties of these numbers are different. So then of >> course: >> >> [(== 1 1N 1.0) (== 1 1N 1.0 1M) (== 1 1N 1.0 1.0M) (== 1 1.0 1N 1.0M)] >> ; => [true true true false] >> and >> [(== 1.0M 1.0) (== 1.0 1) (== 1 1N) (== 1N 1.0M)] >> ; => [true true true false] >> >> I find your lack of transitivity (and commutativity) ... disturbing. >> >> The issue is that there are two notions of equality for BigDecimal, >> equals and compareTo, where equals compares value *and* scale while >> compareTo compares numerically. >> >> The other numeric types use equals for equivalence, quite reasonably. >> But in class BigDecimalOps in clojure/lang/Numbers.java, I propose >> that >> >> public boolean equiv(Number x, Number y){ >> return toBigDecimal(x).equals(toBigDecimal(y)); >> } >> >> should be >> >> public boolean equiv(Number x, Number y){ >> return toBigDecimal(x).compareTo(toBigDecimal(y)) == 0; >> } >> >> to give the proper sense of equivalence. >> >> I haven't had a chance yet to recompile with this change to test it, >> but we do have >> >> (zero? (. 1.0M (compareTo 1M))) ; => true >> (zero? (. 1.0000M (compareTo 1M))) ; => true >> (zero? (. 1.000M (compareTo 1.0M))) ; => true >> >> as desired. >> >> Reactions? >> >> Best, >> >> Chris >> >> -- >> -- >> 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 >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
