Equality comparison in 1.3
Chris Perkins
Daniel
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.
Sean Corfield
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) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/
Railo Technologies, Inc. -- http://www.getrailo.com/
"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)
Stuart Halloway
user=> (= 23.0 23)
false
user=> (= 23 23)
true
Chris Perkins
Stuart Halloway
Chris Perkins
Luc Prefontaine
#'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 3.0 and 3 to be equal else where,
it's a matter of consistency.
Luc P.
--
Luc P.
================
The rabid Muppet
Daniel
Documentation+for+1.3+Numerics). We're all on the same page now. (=
> If the doc string is confusing, please propose alternate language.
adding "...,but not between floating points and integer types."
This kind of change in equality semantics seems prone to cause really
sinister bugs in old 1.2 programs not well unit tested, so I've got a
general concern that there's no easy upgrade (like an =' (prime)) for
old programs that may have relied on this documented functionality.
Chris Perkins
Daniel
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.
Luc Prefontaine
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 key: 3
user=> (= 3.0 3)
true
user=> {3.0 :a 3 :b}
{3.0 :a, 3 :b}
This is non sense, if 3.0 and 3 are to be equal, then the last map should also fail
with a duplicate entry.
It's an inconsistent behavior.
--
Chris Perkins
Luc Prefontaine
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 not floating point values.
The same issues could arise if we allow cross type equality tests, especially with computed values,
giving a false impression of a defined behavior.
If you have nearly equal values between an int (or long) and a floating point value, where do round up ?
Is it fine to round up the decimals or dropping them because they are "not significant" ?
For whom ? How often does a floating point value end up with no decimals following a computation ?
The above is a can of worms especially in heavy computation algorithms.
If Clojure stays on the most accepted side of the fence, then all the semantic issues that do not respect
this must change.
I would rather see something like this in the code:
(= 3 (long 3.8))
or even better
(= 3 (trunc 3.8))
Which clearly states what we want to test.
Luc P.
--