I think this is intended behavior but I don't think it has to be. As a point of note: in Python 64bit, 0 hashes to 0 and None hashes to -9223372036569824492. I guess the thought being there that a hash collision between None and 0 is way more likely than a collision between None and -9223372036569824492.
On Thu, Dec 20, 2012 at 11:04 AM, Stathis Sideris <[email protected]> wrote: > Hello, > > I noticed the following: > > > (hash 0) > 0 > > (hash nil) > 0 > > Which is fair enough I suppose. It seems to have the following side-effect > though: > > > (hash [1 2 3 0]) > 955327 > > (hash [1 2 3 nil]) > 955327 > > Is that the intended behaviour? I suppose it's OK for two things to hash > to the same value, but IMHO, it would make the hash function more useful to > avoid this simple case. The implementation seems to check for nil > specifically and to return 0. > > Thanks, > > Stathis > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to [email protected] > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en
