Yes, the Clojure 1.3 doc is wrong. As a new Clojure user, I was pretty
confused for a while.
But after reading this thread I still don't understand why the map behavior
(where 3 and 3.0 are considered different map keys) wasn't considered
incorrect, rather than the = behavior.
core.clj currently contains two definitions of =, one of which is commented
out. The active one has this docstring:
Equality. Returns true if x equals y, false if not. Same as
Java x.equals(y) except it also works for nil, and compares
numbers and collections in a type-independent manner.
On Sat, Oct 1, 2011 at 9:52 PM, Daniel doubleagen...@gmail.com wrote:
user= (= 23.0 23)
false
With every language I've ever worked in, I've always been told that
comparing floating point numbers for equality is a bad idea so I'm
actually glad to see that the above comparison is false...
--
user= (= 23.0 23)
false
user= (= 23 23)
true
This is the correct behavior. If the doc string is confusing, please propose
alternate language.
Stu
Stuart Halloway
Clojure/core
http://clojure.com
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To
Follow-up question: Can someone explain the rationale behind the change to =
semantics between integers and floating-point numbers? I have read the
design page (
http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics), but all
it seems to have is this somewhat cryptic description:
user= (def m { 3.0 :a 3 :b})
#'user/a
user= a
{3.0 :a, 3 :b}
user= (get m 3.0 )
:a
user= (get m 3 )
:b
user=
if 3.0 and 3 were to be considered equals, you could not represent the above
map,
the second entry would squash the first.
Now if we want to allow such maps, then we cannot consider
Right. I didn't see this earlier (http://dev.clojure.org/display/doc/
Documentation+for+1.3+Numerics). We're all on the same page now. (=
If the doc string is confusing, please propose alternate language.
Updating the '=' docstring to match that page sounds appropriate ie
adding ...,but not
Luc,
I think you are mistaken.
user= (clojure-version)
1.2.1
user= (def m {3.0 :a 3 :b})
#'user/m
user= (get m 3.0)
:a
user= (get m 3)
:b
user= (= 3 3.0)
true
user=
Do you have another example?
- Chris
--
You received this message because you are subscribed to the Google
Groups Clojure
I think he's saying that it boiled down to consistency ie it's
inconsistent to allow maps where 3 != 3.0, but make 3 = 3.0 fit
clojure equality semantics. I don't know if that's satisfying, but
it's fair.
On Oct 2, 3:31 pm, Chris Perkins chrisperkin...@gmail.com wrote:
Luc,
I think you are
What I meant is that (= 3 3.0) is the erroneous behavior.
Either it's equal every where (including as keys in maps) or not.
You cannot have both semantics coexists. It's all or nothing.
Look at this the other way around (1.2):
user= {3 :a 3 :b}
java.lang.IllegalArgumentException: Duplicate
Ok, I follow you now. That makes sense. Sort-of :)
On the other hand, it's only inconsistent if you consider clojure's = to map
to java's .equals method, but it does not:
user= (clojure-version)
1.2.1
user= (= 3 3.0)
true
user= (.equals 3 3.0)
false
So it doesn't really violate the contract
In practice, in most languages, it's uncertain to test for equality between
floating point values.
This is mainly a side effect of internal representations.
http://www.cygnus-software.com/papers/comparingfloats/comparingfloats.htm
It's probably safer to keep things that way. Ints (or longs) are
I am trying to upgrade some code to 1.3, and I'm not sure how to do the
equivalent of a 1.2-style equality comparison.
user (= {:foo 23} {:foo 23.0})
false
This used to be true. I see that = is now documented to compare same-type
numbers only, but == can be used for 1.2-compatible
user= (= 23.0 23)
false
user= (= 23 23)
true
compares numbers and collections in a type-independent manner
This kind of breakage was probably to be expected with the numerics
changes in 1.3. I am also interested in this.
On Oct 1, 4:34 pm, Chris Perkins chrisperkin...@gmail.com wrote:
I am
14 matches
Mail list logo
