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 for double and float hashes uses Java's hash algorithm, which uses IEEE 754 bit representation of floats, that is a fast native function [1], but is different for doubles and floats. While Murmur3 does provide hashing for integer numbers, there is no hash function for floating point ones. And note that there are big decimals too... > (hash 1.5) 1073217536 > (hash 1.5M) 466 > (hash (float 1.5)) 1069547520 [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/a7dd84b9557c/src/share/classes/java/lang/Double.java#l761 Jozef On Thu, Jan 22, 2015 at 4:36 PM, Luc Préfontaine < lprefonta...@softaddicts.ca> wrote: > 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 impression that everything is fine. > > Floats and doubles do not have the same precision/representation and thus > comparing > for equal values without explicit casting/truncating/rounding cannot be > relied on. > These are JVM native types. Even Java folks ask this question about > equality on a regular > basis and its their language of choice :) > > Have a look at IEE floating point representations that will give you an > idea of the scope > of the problem. > > In the past I used to deal with up to 4 different representations on the > same hardware. > We would never mix them, we would convert them at the edge of our app or > within > very narrow boundaries. > > Even business apps in Cobol had issues with this, not all hardware > supported packed > decimal operations, relying on some floating point representation better > handled by > hardware was common with all the conversion problems related > (rounding/truncating > in computations, ...). We could even choose the runtime float > representation to > minimize errors in computations and take the best one given the app at > hand. > > Avoid mixing them. That's the only safe escape. > > Luc P. > > > 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 > > > > Plínio > > > > On Thu, Jan 22, 2015 at 12:18 PM, Andy Fingerhut < > andy.finger...@gmail.com> > > wrote: > > > > > "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 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 1.6)) > > >> 1.600000023841858 > > >> user=> (.doubleValue (float 1.5)) > > >> 1.5 > > >> > > >> I'm not sure why floats are not handled specially in Numbers.java so > > >> that hash/comparision is handled consistently with doubles (e.g. by > > >> converting the floats to the fitting double via Double.parseDouble), > > >> the current behaviour seems odd to me. > > >> > > >> Jozef Wagner writes: > > >> > > >> > 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 > > >> >> user=> (map hash [(float 0.5) (double 0.5)]) > > >> >> (1056964608 1071644672) > > >> >> > > >> >> Nicola Mometto writes: > > >> >> > > >> >> > Looks like it's a bug in PersistentHashMap: > > >> >> > user=> (contains? (hash-map {:a (float 0.5)} 1) {:a (double 05)}) > > >> >> > 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 > > >> >> >> (= {: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 > > >> >> Groups "Clojure" group. > > >> >> To post to this group, send email to clojure@googlegroups.com > > >> >> Note that posts from new members are moderated - please be patient > with > > >> >> your first post. > > >> >> To unsubscribe from this group, send email to > > >> >> clojure+unsubscr...@googlegroups.com > > >> >> For more options, visit this group at > > >> >> http://groups.google.com/group/clojure?hl=en > > >> >> --- > > >> >> You received this message because you are subscribed to the Google > > >> Groups > > >> >> "Clojure" group. > > >> >> To unsubscribe from this group and stop receiving emails from it, > send > > >> an > > >> >> email to clojure+unsubscr...@googlegroups.com. > > >> >> For more options, visit https://groups.google.com/d/optout. > > >> >> > > >> > > >> -- > > >> > > >> -- > > >> 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 patient > with > > >> your first post. > > >> To unsubscribe from this group, send email to > > >> clojure+unsubscr...@googlegroups.com > > >> For more options, visit this group at > > >> http://groups.google.com/group/clojure?hl=en > > >> --- > > >> You received this message because you are subscribed to the Google > Groups > > >> "Clojure" group. > > >> To unsubscribe from this group and stop receiving emails from it, > send an > > >> email to clojure+unsubscr...@googlegroups.com. > > >> For more options, visit https://groups.google.com/d/optout. > > >> > > > > > > -- > > > 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 patient with > > > your first post. > > > To unsubscribe from this group, send email to > > > clojure+unsubscr...@googlegroups.com > > > For more options, visit this group at > > > http://groups.google.com/group/clojure?hl=en > > > --- > > > You received this message because you are subscribed to the Google > Groups > > > "Clojure" group. > > > To unsubscribe from this group and stop receiving emails from it, send > an > > > email to clojure+unsubscr...@googlegroups.com. > > > For more options, visit https://groups.google.com/d/optout. > > > > > > > -- > > 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 patient with > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/clojure?hl=en > > --- > > You received this message because you are subscribed to the Google > Groups "Clojure" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > > -- > Luc Préfontaine<lprefonta...@softaddicts.ca> sent by ibisMail! > > -- > 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 patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
