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.
