Re: Interesting integer behavior
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 behavior. Odd no longer - thanks for the report! 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 For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Interesting integer behavior
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 because of: user (class (+ 2147483647 1)) java.lang.Long user= (class (inc (inc 2147483647))) java.lang.Long BigIntegerOps reduces to Long if possible. This isn't *technically* a bug, but it is an odd behavior. fixed by this: http://github.com/juergenhoetzel/clojure/commit/a47e9cc9f1a8434b677184848c641f19ed455b54 Jürgen -- 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
Re: Interesting integer behavior
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){
int bitLength = val.bitLength();
if(bitLength 32)
return val.intValue();
else if(bitLength 64)
return val.longValue();
else
return val;
}
The class that operates on Integers, IntegerOps, doesn't have an
equivalent reduce() method.
On Mar 11, 7:53 am, 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 behavior.
Brian
--
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
Re: Interesting integer 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 2147493748. Because of the way maps and sets work, it is rather important that there be exactly one standard type for each number produced by standard Clojure arithmetic (if you use Java math, all bets are off). -- 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
Interesting integer behavior
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 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
