>>> 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. > > That does not make sense, since the implementations in both cases have > to test for overflow and branch. In the "overflowed" branch further > expensive actions are taken -- in both cases the creation of a Java > object, for instance (an exception or a boxed numeric). These branches > might differ in other ways in speed, but they're the rare case. The > common case is test and accept the result, returning it, in both > cases; so the common case should have comparable execution speed given > both implementations. If not, something is wrong someplace else with > at least one of the implementations (or, much less likely, with the > JVM/JIT).
It will make sense once you understand the implications of primitives and objects not being unified, which come into play before the test for overflow, and hurt you even in applications where overflow never happens. If this thread is not sufficiently clear on that point, and you don't have time to run tests for yourself, can I ask that you please hold off on beating this dead horse until we can >> 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. > > As for "broken", you can't honestly think changing the semantics of > the + operator, after years of code written in Clojure has > accumulated, won't break *something*. Surely. Most likely many > somethings, scattered all over the place. That's why it is called a breaking change. :-) We have (and will continue to have) a large number of prereleases for people to shake out issues. 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
