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 [email protected]
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
