Can you provide a couple of concrete examples for this? I will make the ticket in JIRA and start working on it, but I am spread thin on quite a few things at the moment and these examples will help a lot.
Cheers, Aaron Bedra -- Clojure/core http://clojure.com On Jun 24, 12:47 pm, Mark Engelberg <mark.engelb...@gmail.com> wrote: > One of the main changes to1.3is that arithmetic operations on longs > do not automatically overflow. > > In the early discussions of this new feature, it was pointed out that > people who want overflow capability can use the special "prime" > operators, but that the preferred way to do things would be to write > functions in such a way that you can pass in bigints if you want > overflow. > > But it was also pointed out that passing in bigints to ensure overflow > would be a huge performance hit over 1.2 for cases where overflow only > happens sometimes, because this forces bigint math to happen all the > time, which is substantially slower thanClojure'sexisting strategy > of doing math on longs and only switching to slower bigint math when > overflow actually occurs. > > To resolve this, it was proposed thatClojurewould use its own BigInt > class rather than Java's built-in. It would start off as a stub that > forwarded everything to Java's implementation, but would eventually be > converted to a more intelligent interpretation that works more > likeClojure'sexisting system -- numbers small enough to be represented as > Ints or Longs would be represented that way and benefit from faster > computation. > > As far as I know, the stub class was indeed implemented to preserve > the option to make these optimizations, but no one has actually > refined the BigInt class. I propose that these optimizations should > be done beforeClojure1.3goes final, because this is a really > important part of ensuring good numeric performance for applications > that were previously taking advantage ofClojure'sability to handle > overflows. If this isn't done byClojure1.3final, we're going to > end up with a body of code that, by necessity, uses the prime > operators, because the preferred strategy of passing in bigints will > be impractically slow. If we want to get people to use the idiom of > using non-prime operators and passing in bigints, we need to make sure > this approach performs well for the final release. -- 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
