On Mar 10, 3:53 pm, Brian Hurt bhur...@gmail.com wrote:
In a recent clojure:
user= (class 2147483647)
java.lang.Integer
user= (class (inc 2147483647))
java.math.BigInteger
user= (class (inc (inc 2147483647)))
java.lang.Long
user=
This isn't *technically* a bug, but it is an odd
Hi,
2010/3/10 Brian Hurt bhur...@gmail.com:
In a recent clojure:
user= (class 2147483647)
java.lang.Integer
user= (class (inc 2147483647))
java.math.BigInteger
upcasted to BigInteger because of overflow detection in IntegerOps,
even though a cast to Long would be sufficient. Also odd
I took a look at the code for Clojure 1.1, in clojure.lang.Numbers,
and it seems that results of numerical ops on BigIntegers
(BigIntegerOps) are passed to a 'reduce' method, which appears to
return the most economical representation of a number:
static public Number reduce(BigInteger
If (inc 21471493647) and (+ 1 21471493647) produce different types of
numbers, I would definitely categorize this as a bug and not just strange
behavior. This means that if you use 2147493748 as a key in a map or set
it might work improperly depending on what computation you used to arrive at
In a recent clojure:
user= (class 2147483647)
java.lang.Integer
user= (class (inc 2147483647))
java.math.BigInteger
user= (class (inc (inc 2147483647)))
java.lang.Long
user=
This isn't *technically* a bug, but it is an odd behavior.
Brian
--
You received this message because you are
