Following up, point (2) in my previous message would be helpful only if = were changed so that it looked at the stripTrailingZeros() value of BigDecimals. I would advocate this in any case, because the following behavior appears silly to me (is it useful to anyone?):
user=> (== 434343.00M 434343.0M) ;BigDecimal works this way, apparently false user=> (= 434343.00M 434343.0M) ;odd, however false user=> (= 434343.00M 434343.0) false user=> (== 434343.00M 434343.0) ;even odder, in my opinion, given the above true user=> (= (.stripTrailingZeros 434343.00M) (.stripTrailingZeros 434343.0M)) ;shouldn't = default to this? true Garth On Fri, Jun 25, 2010 at 4:18 PM, Garth Sheldon-Coulson <g...@mit.edu> wrote: > 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
