Thanks for the historical perspective, puzzler!
In addition to performance considerations, *Clojure Programming* points to
an inconsistency between hash codes for longs and BigIntegers as a
motivation.
Using the example number from that excellent book on Clojure 1.5.1 (on Java
8, FWIW), I can cause this:
#{6948736584 (biginteger 6948736584)}
; => #{6948736584 6948736584}
#{6948736584 (bigint 6948736584)}
; => IllegalArgumentException Duplicate key: 6948736584
clojure.lang.PersistentHashSet.createWithCheck (PersistentHashSet.java:56)
(System/getProperty "java.version")
; => "1.8.0_05"
(clojure-version)
; => "1.5.1"
On Clojure 1.6, thankfully both fail, even in the face of the inconsistency
between .hashCode implementations. If that essentially addresses the 2nd
rationale for introducing a special BigInt class, maybe with both things
being fixed with Java 8 and Clojure 1.6 BigInteger could come back as the
sole arbitrary precision representation of ℤ.
--
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.
