On Mar 10, 3:53 pm, Brian Hurt 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 behavior.
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
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 val)
Hi,
2010/3/10 Brian Hurt :
> 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 because of:
us
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 subsc
