On Mar 30, 1:45 pm, Mark Engelberg <mark.engelb...@gmail.com> wrote:
> 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.
This 'fix' isn't viable - there are plenty of cases where people might
want to always use, e.g. Longs as keys.
Rich
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
