This looks excellent. I'd like to re-raise a question I had a few days ago: Will this ultimately come to affect floats, too?
In particular: 1) If there is going to be BigInt contagion, why not BigDecimal contagion? user=> (* 4 5) 20 user=> (* 4 5N) 20N but user=> (* 4.0 5.0) 20.0 user=> (* 4.0 5.0M) ;no contagion 20.0 user=> (* 4.0M 5.0M) 20.00M user=> (* 4.0 5.0000000000000000001M) ;not even when it's needed 20.0 user=> (* 4.0M 5.0000000000000000001M) 20.00000000000000000040M 2) Will the same reasoning that produced BigInt give us a BigDec with a better hashCode() than that of BigDecimal? user=> (hash 4343434343) 48467046 user=> (hash (BigInteger. "4343434343")) ;not very nice 48467078 user=> (hash 4343434343N) ;nice as of equiv branch 48467046 but user=> (hash 4343.4343) 1861754824 user=> (hash 4343.4343M) ;not very nice 1346464637 user=> (defn -hashCode [this] (let [dv (.doubleValue this)] (if (== this dv) (.hashCode dv) (.hashCode this)))) #'user/-hashCode user=> (hash 4343.4343) 1861754824 user=> (-hashCode 4343.4343M) ;nicer 1861754824 Garth On Fri, Jun 25, 2010 at 3:04 PM, Rich Hickey <richhic...@gmail.com> wrote: > equiv, the revenge of num > > The latest revision of primitive support is in the equiv branch. It takes > the approach of num, with no auto-promotion, and bigint contagion, and adds > several things to better support contagion. I think contagion is the best > way to continue to support polymorphic numeric code, something I consider > important. > > Contagion has several issues. First and foremost, it means that it it will > be possible for 42 and 42N to be produced in the course of normal > operations, so strict type-specific equality is not a good match. The equiv > branch brings back equivalence-based =, with a slightly tighter notion of =, > supporting only similar categories of numbers, so (= 42 42.0) => false, but > (= 42 42N) => true. == is still available. > > The second problem is the use of numbers (and collections of numbers) as > keys in hash maps and members of hash sets. We already had an issue here, as > there wasn't completely uniform boxing, and there will always be the > possibility of numbers from the outside. The equal branch tried to use > consistent boxing and type-specific =, but it was still open to mismatch > with numbers from outside. The equiv branch extends = to keys and set > members when used from Clojure, i.e. Clojure get and contains will use = > logic, while the Java get and containsKey will use .equals(). I.e. we will > still satisfy the semantics of Java when used through the Java APIs, but > nothing said the Clojure API must match those semantics. When combined with > the new BigInt class (see below), this will allow you to look up (and find!) > the integer 42 with either 42 or 42N. > > The equiv branch also has a new BigInt type. This is strictly necessary for > this scheme, as Java's BigIntegers and Longs can produce different hashCodes > for the same values. In addition to matching hashCode support, the BigInt > class opens the door to better performance when used with numbers > long-or-smaller. These performance enhancements have not yet been made. > > More details have been added to the top here: > > > https://www.assembla.com/wiki/show/b4-TTcvBSr3RAZeJe5aVNr/Enhanced_Primitive_Support > > Code is here: > > http://github.com/richhickey/clojure/commits/equiv > > > Feedback welcome, > > 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 > 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<clojure%2bunsubscr...@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 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