I must agree that the behaviour of == is not correct here.
The problem is in this method in Numbers.java:
public boolean equiv(Number x, Number y){
return toBigDecimal(x).equals(toBigDecimal(y));
}
The behaviour we currently have is:
user= (let [ones [1 1.0 1N 1M 1.0M 1.00M] ] (doseq [a
Leif leif.poor...@gmail.com writes:
I'd also like to make sure people are aware of this oddity. I
discovered this after reading an article about the bad design of PHP.
I read that in PHP, == is not transitive. I thought Ha ha ha, that
ridiculous PHP!
Then I checked c.c/== ; Imagine my
Yes, that is one reason why I tend to use BigDecimal instead of float
or double. The thing that seems wrong to me is (not (== 1 1.0M)),
since these are both exact representations of the value one and the
doc for == says that it tests for equivalent value (type-
independent).
On Apr 11, 10:00 pm,
I'd also like to make sure people are aware of this oddity. I discovered
this after reading an article about the bad design of PHP. I read that in
PHP, == is not transitive. I thought Ha ha ha, that ridiculous PHP!
Then I checked c.c/== ; Imagine my reaction when I learned that Clojure
IME, it's almost never useful to perform equality tests on floating
point values. Generally you want to know if they're near enough to one
another without necessarily being exactly equal. For that something
like (defn f= [f1 f2 threshold] ( (Math/abs (- f1 f2)) threshold)) is
probably the sort of
On Wed, Apr 11, 2012 at 5:46 PM, Leif leif.poor...@gmail.com wrote:
Then I checked c.c/== ; Imagine my reaction when I learned that Clojure had
something in common with PHP. o_O, :'[
It's instructive to look at the result of:
(let [ones [1 1.0 1N 1M 1.0M] ] (for [a ones b ones] (== a b)))
Greetings,
I think that I've encountered a bug in ==.
user= (and (== 1 1.0) (== 1.0 1.0M) (not (== 1 1.0M)))
true
This happens with 1.2.1 and 1.3-beta2. I think it has to do with the
precision of the BigDecimal.
user= (== 1 1.0M)
false
user= (== 1 1M)
true
I think a solution would be to use
