My own opinions: I don't expect 1 to equal 1.0 (because I think of inexact numbers as fundamentally different from exact numbers). I think of 1.0 as a "number that's so close to 1 that we can't tell the difference, but it still might not be 1". I do expect 1 to equal 1/1, and I expect a long 1 to equal an int 1 to equal a BigInteger 1. I think of these as all different ways of writing or storing the same number.
I also expect 1 to equal 1.0M (which currently it does not) since 1.0M is also an exact representation of the same number. But it's a sufficiently different representation, it doesn't bother me as much to have these treated as not-equal. A fix that would feel consistent to me: Drop equality of 1 and 1.0. Alter hash-map and hash-set to special case on assoc,dissoc,getting Longs and BigIntegers to always clojure.lang.Numbers/reduce these keys before storing and/or comparing in the hash table. So only reduced integers will ever be stored as keys, and different representations of the same value will behave as expected. I don't know whether this fix would be worth the performance penalty, though, but it's what would "feel right" to me. --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
