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 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 >
Things that don't have the same hash shouldn't compare equal, at least so long as one avoids mutable java.util collections. If floats and doubles can't generally have the same hashes (let alone floats and BigDecimals) then = should return false for any comparison of two different of these three types (and numerical code that wants to check for numerical equality across types, to the extent that ever makes sense with FP types, should use ==). -- 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.
