Hi, Am Donnerstag, 8. September 2011 14:21:09 UTC+2 schrieb Dominikus: > > Right, this feature is documented in > http://dev.clojure.org/display/doc/Documentation+for+1.3+Numerics > > For me it feels somewhat strange to use "primed" operations to enforce > upgrade casting and to write a special faculty function for that. >
This is the trade-off between safe/fast and safe/slow. > I just discovered that (fact 21) breaks while (fact 21N) does not but > (fact 22N) does: > > Weird! > This is due to the fact, that the overflow in (fact 21) happens in the *. With (fact 21N) this works because the 21N promotes the * to a BigInt operation and (fact 20) still fits into a long. So everything works here. With (fact 22N) the (- 22N 1) demotes the 21 to a long (<-- Here is the bug) since it small enough to fit in there. Then we are in the (fact 21) situation again. Please keep in mind, that this behaviour is due to a bug in the current BigInt implementation! Normally a (fact 21N) would just work. The BigInt should use long arithmetic internally if possible. But the "re-promotion" to a "real" BigInt doesn't work correctly. Sincerely Meikel -- 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
