> Worse, from the sounds of it the new + isn't exactly the old > unchecked-+; it still checks for overflow rather than allowing > wrapping. That's going to add a compare-and-branch to every add > instruction and halve the speed of those operators on typical > hardware. Compare-and-throw-exception is hardly superior to > compare-and-box-in-BigInteger, since it's still slow AND now some > arithmetic code that used to work but be slow will now explode in your > face.
This argument is based on the (provably wrong) presumption that "still slow" means "equally slow". The difference is percentage points vs. order of magnitude. Test it for yourself. The Clojure/core team has an action item to pull the docs on the numeric stuff into one place so that it is easier to point people to a single location and prevent rehashing old issues. Until that is done, if you want to continue this thread, please make arguments that back up notions like "slow" or "fast" or "broken" with evidence from real code. Stu -- 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
