Alex, Am Samstag, 24. Juni 2017 13:38:55 UTC schrieb Alex Miller: > > > Due to how single and double precision floats are stored, you'll get these > same results in Java too. These will store differently imprecise > representations of the number (remember base 2, not 10). > > user=> (Integer/toBinaryString (int (Float/floatToRawIntBits (float 0.2)))) > "111110010011001100110011001101" > user=> (Long/toBinaryString (Double/doubleToRawLongBits 0.2)) > "11111111001001100110011001100110011001100110011001100110011010" > > More: > http://steve.hollasch.net/cgindex/coding/ieeefloat.html > > https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ >
Thanks for your reply. Yes, I know. Here https://github.com/henrik42/java-quiz#numberquiz I wrote down some of the "interesting cases". The reason for this is that Clojure doesn't support floats - we only read > fixed precision floating point as doubles, period. How would the reader > know whether to read single or double precision? It would have to make a > decision on whether to make a float or a double, which is inherently > sketchy. The use cases for single precision floats even in Java are almost > entirely gone at this point. The only time you'd want to use them is if you > want floating point math with the smallest possible memory (and are willing > to give up the corresponding reduction in precision). > Oh, I thought because there is the float-function floats are supported. Clojure could use "0.2f" to print/read floats and still use double "0.2" as the default (but float's "Infinity" may be challenging ;-) Java uses f2d when comparing float vs. double and when mixing floats and double for +/-/etc. All I'm saying is that Clojure *could* use (Double. (str f)) instead of f2d in these cases. That would make (= (double 0.2) (Double. (str (float 0.2)))) ;; -> true Talking about infinity: #{Double/POSITIVE_INFINITY} ;; -> #{Infinity} But #{Infinity} ;; -> Exception: Unable to resolve symbol: Infinity in this context. Is there a way to deal with this at the moment? > This is under discussion in a ticket at > http://dev.clojure.org/jira/browse/CLJ-1649. It is definitely a bug with > float/double hash consistency. My personal vote in this case is that floats > and doubles should just never compare equals, period. Due to the example up > top, you're almost never going to get predictable results and you should > just not use floats. Or at least not use a mix of floats and doubles. > And throw an exception when doing so? Or is it GIGO? Andy Fingerhut has a comprehensive page on equality at > https://github.com/jafingerhut/thalia/blob/master/doc/other-topics/equality.md. > > I have an extensive rewrite of this destined to be a guide on the Clojure > site, but it's still a work in progress at this point. > > I'll read that. Thanks. Henrik -- 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.