Thanks for the explanation, Meikel! I'll wait for the next release which hopefully fixes the bug.
Cheers, Dominikus On Sep 8, 2:31 pm, "Meikel Brandmeyer (kotarak)" <m...@kotka.de> wrote: > 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
