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.
http://clojure.
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.
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
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 contr
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 ke
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 wrote:
> Luc,
>
> I think you are mistaken.
>
> user=> (cl
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 "Cloj
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
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 conside
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:
"
> Stuart,
>
> The documentation is clear (to me) about comparing numbers directly - that
> part is fine. My question was about whether there is an equivalent of the new
> == comparison that works on containers with floating-point numbers inside.
>
> I had guessed that == would recursively compa
Stuart,
The documentation is clear (to me) about comparing numbers directly - that
part is fine. My question was about whether there is an equivalent of the
new == comparison that works on containers with floating-point numbers
inside.
I had guessed that == would recursively compare the conten
> 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" gr
On Sat, Oct 1, 2011 at 9:52 PM, Daniel 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...
--
Sean A Corfield -- (904)
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 wrote:
> I am trying to upgrade so
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 comparisons
16 matches
Mail list logo
