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 o
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
>
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
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 li
On Jan 23, 2015, at 11:51 AM, Andy Fingerhut 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 1.5))
> true
> user
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 1
On Jan 23, 2015, at 8:23 AM, Andy Fingerhut 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 subscribed to the Google
Grou
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. Witho
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 obje
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 =
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 i
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
> wrote:
>
> Agree, it's broken... in java...
> Has it has b
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
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 representations.
On Jan 23, 2015, at 1:33 AM, Immo Heikkinen 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, it
> is inevitable
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 hou
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 consi
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 th
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 implementation
And how to you want to proceed knowing that floats and double can escape
elsewhere in your app and create the same chaotic effect like for example,
in some interop call to some obscure library ?
The best ... consistency here seems to reflect what's occurring underneath
instead
of giving the false
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.
+ Do
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
"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 wrote:
>
> Not sure if this is intended behaviour:
> user=> (= (float 1.6) (double 1.6))
> false
>
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
More on this behavior http://dev.clojure.org/jira/browse/CLJ-1036
On Thu, Jan 22, 2015 at 2:00 PM, Nicola Mometto 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
> user=> (map ha
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)})
> =>
(= (float 0.5) (double 0.5))
=> true
(= #{(float 0.5)} #{(double 0.5)})
=> true
(= {:a (float 0.5)} {:a (double 0.5)})
=> true
(= #{{:a (float 0.5)}} #{{:a (double 0.5)}})
=> false
Tested with both 1.6.0 and 1.7.0-alpha5.
--
You received this message because you are subscribed to the Google
Gro
29 matches
Mail list logo