On Tue, Dec 14, 2010 at 6:04 PM, Ken Wesson <kwess...@gmail.com> wrote:
> On Tue, Dec 14, 2010 at 8:23 PM, Benny Tsai <benny.t...@gmail.com> wrote: > > As Brian said, primitive math is now the default in 1.3. If auto- > > promotion on overflow is desired, you can use the +', -', *', inc', > > dec' functions (note the single quote suffix). > > Why was this done? I preferred having +, -, etc. DTRT in general and > unchecked-+, etc. for when you really needed efficient primitive math. > My code is littered with + but has few unchecked-+s. Which means I'll > have to go through it all adding little tick-marks everywhere and > making the math look funny to keep its behavior the same whenever 1.3 > is released. > > Search the archives for "enhanced primitive support". There was a big battle back in June. People like you and me, who don't want to have to think about whether their code might crash with certain inputs from arithmetic overflow, lost the battle to those who want to get more speed out of Clojure without having to specifically annotate tight loops with special primitive math ops. The theory is that most programs work perfectly fine with longs. If yours doesn't, you'll hopefully find out when it throws an error, and go annotate your code accordingly. In exchange, Clojure will supposedly get faster for the common case. In practice, I haven't seen a significant speed improvement in the new branch of Clojure (except on specific benchmarks that intentionally test Clojure's new default primitive math). In my day-to-day code, all my numbers, despite being perfectly small enough to fit in a long, end up getting stored and retrieved from Clojure's various data structures - vectors, maps, sets, etc. and thus lose their primitiveness. So I presumably haven't seen any speed improvement because all the numbers are boxed by the time I do math on them. Fortunately, I also don't seem to run into arithmetic overflows because my production code isn't particularly math intensive, but I still end up feeling stressed out trying to convince myself that it can't ever overflow for any input. It will be interesting to see how this all shakes out -- whether there are more ways to exploit the default of primitive math for better speed, and whether people still like the new direction after trying it more. -- 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
