On Jan 23, 2015, at 8:23 AM, Andy Fingerhut andy.finger...@gmail.com wrote:
You can try creating a JIRA ticket suggesting that Clojure's = should return
false when comparing floats and doubles to each other.
CLJ-1649, for anyone interested.
--
You received this message because you are
Danger vs flexibility.
or are safe. Should they throw an exception then ?
Compiler in some older typed languages would warn you about testing equality
between two float numbers irrelevant of their types but would be silent about
other operators.
Testing equality with floats is seldom used
Not sure which properties you prefer to be true in programming languages
you use. Hash consistency is certainly nice, but if Clojure were changed
such that (= float-val double-val) were always false, and no other changes
were made, it would lead to this situation:
user= (= (float 1.5) (double
On Jan 23, 2015, at 11:51 AM, Andy Fingerhut andy.finger...@gmail.com wrote:
Hash consistency is certainly nice, but if Clojure were changed such that (=
float-val double-val) were always false, and no other changes were made, it
would lead to this situation:
user= (= (float 1.5) (double
If the underlying argument is that it is horribly dangerous to mix floats
and doubles in your code, then maybe (= (float 1.5) (double 1.5)) should
have the semantics of (.compareTo (float 1.5) (double 1.5)), i.e., throw an
error.
I'm not certain that's a good idea for Clojure, but it does seem
And this is not a typeless language, it is a strongly dynamically typed
language.
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be
On Friday, January 23, 2015 at 1:27:18 PM UTC-5, Luc wrote:
Danger vs flexibility.
or are safe. Should they throw an exception then ?
Compiler in some older typed languages would warn you about testing
equality between two float numbers irrelevant of their types but would be
silent
Obviously...
user= (= (byte 1) (short 1) (long 1) 1)
true
user=
http://clojure.org/rationale
Language as platform vs. language + platform
- Old way - each language defines its own runtime
GC, bytecode, type system, libraries etc
- New way (JVM, .Net)
- Common runtime independent of
I'm sure we are all aware of the various issues with floating point math
(particularly equality comparisons); however none of that is relevant to this
discussion. The only issue here is an inconsistency between hashing and
equality testing in Clojure.
My claim is that the property any two
On Jan 23, 2015, at 1:33 AM, Immo Heikkinen immo.heikki...@gmail.com wrote:
I actually ran into this while comparing nested data structures from two
different sources and spent a good part of my day figuring out what's
happening. While it is a good advice to avoid mixing floats and doubles,
Agree, it's broken... in java...
Has it has been broken in the past in several architectures...
I understand your frustration but this is not something new. It's been a
problem for at least 30 years.
It is kind of a basic programming issue:
- Never compare floats with different
public class TestClass {
public static void equality () {
double dd = 3.5;
float ff = 3.5f;
System.out.println(String.format(dd vs ff == %b, dd==ff));
double dd2 = 3.2;
float ff2 =
On Fri, Jan 23, 2015 at 1:10 AM, Luc Prefontaine
lprefonta...@softaddicts.ca wrote:
Agree, it's broken... in java...
I think it's more frustrating in Clojure than in Java, though, because in
Java you have those big, ugly type annotations on every single variable,
input and output, so there's
If there's a technical reason why Clojure can't return false for all =
comparisons between floats and doubles, I'd like to hear it. Otherwise, I don't
see how your response is relevant.
On Jan 23, 2015, at 3:10 AM, Luc Prefontaine lprefonta...@softaddicts.ca
wrote:
Agree, it's broken...
Well if it breaks elsewhere than in your code because you mix representations
and leak
them to some library in Java that you do not control I see my comments as
absolutely relevant.
It's not technical, it's failsafe. But that might not be of any interest to
your problem scope.
However it does
Michael:
You can try creating a JIRA ticket suggesting that Clojure's = should
return false when comparing floats and doubles to each other. I have no
idea if it would go anywhere, but alternative (2) trying to get hashes to
be equal between = float/doubles has been suggested and declined.
It is out of scope for Clojure to fix this for Java types Float/Double
-- comments in CLJ-1036: http://dev.clojure.org/jira/browse/CLJ-1036
Andy
On Thu, Jan 22, 2015 at 5:53 AM, Nicola Mometto brobro...@gmail.com wrote:
Not sure if this is intended behaviour:
user= (= (float 1.6) (double
Looking at the PHM impl, this looks like it's caused by (float 0.5) and
(double 0.5) hashing differently.
user= (= (float 0.5) (double 0.5))
true
user= (map hash [(float 0.5) (double 0.5)])
(1056964608 1071644672)
Nicola Mometto writes:
Looks like it's a bug in PersistentHashMap:
user=
Looks like it's a bug in PersistentHashMap:
user= (contains? (hash-map {:a (float 0.5)} 1) {:a (double 0.5)})
false
user= (contains? (array-map {:a (float 0.5)} 1) {:a (double 0.5)})
true
Immo Heikkinen writes:
(= (float 0.5) (double 0.5))
= true
(= #{(float 0.5)} #{(double 0.5)})
= true
More on this behavior http://dev.clojure.org/jira/browse/CLJ-1036
On Thu, Jan 22, 2015 at 2:00 PM, Nicola Mometto brobro...@gmail.com wrote:
Looking at the PHM impl, this looks like it's caused by (float 0.5) and
(double 0.5) hashing differently.
user= (= (float 0.5) (double 0.5))
true
Not sure if this is intended behaviour:
user= (= (float 1.6) (double 1.6))
false
user= (= (float 1.5) (double 1.5))
true
I.e. = (and ==) will return true when comparing floats with doubles IFF
the float's .doubleValue roundtrips to the same double it's comparing to.
user= (.doubleValue (float
Part of what you wish were true is already true: Using = to compare a
double to a BigDecimal always returns false in Clojure, as does comparing a
float to a BigDecimal.
It is only (= float-value double-value) that can return true in Clojure,
even though hash does not guarantee the usual hash
On Thursday, January 22, 2015 at 2:12:52 PM UTC-5, Jozef Wagner wrote:
As seen in CLJ-1372, this issue will probably cause some strong opinions.
I think this is an example of a leaky abstraction and the current approach
is to leave it as is, as there are some serious trade-offs and are there
On the side of positive recommendations to avoid problems like this, here
is some advice:
+ Don't mix floats and doubles in the same Clojure program. Given that
Clojure uses double arithmetic by default, it is much easier to use doubles
everywhere than it is to try to use floats everywhere.
+
My one cent:
But I think (and it's just my humble opinion) is in the scope of Clojure
keep its consistency, am I right?
I mean, if doubles and floats are different, and they are, I think we
should always get equality test as false. Or always as true, if they're
nominally the same value.
Regards
As seen in CLJ-1372, this issue will probably cause some strong opinions. I
think this is an example of a leaky abstraction and the current approach is
to leave it as is, as there are some serious trade-offs and are there is no
rationale or real practical reason to fix this.
Current
I actually ran into this while comparing nested data structures from two
different sources and spent a good part of my day figuring out what's
happening. While it is a good advice to avoid mixing floats and doubles, it
is inevitable that Clojure users will get bitten by this once in a while
and
27 matches
Mail list logo
