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
