What's wrong with this definition? sum "(1) This used to use #runsDo:, which can lead to big savings on bags and runarrays, but we almost never use this method on them, so it didn't pay off. (2) The obvious initialisation to 0 doesn't work with a collection of Money, Quantities, Durations, and so on. (3) Since the receiver is almost always a collection of numbers, it would be very bad if #() sum did not answer 0. So we should not use #anyOne. (4) Using #anyOne to select between algorithms required being able to traverse the Enumerable twice, but Enumerable is for things you can only traverse once. Oops. Good thing we want to avoid #anyOne anyway. (5) nil does not and should not respondTo: #+ so we can use a single variable. Watch out for this in other summaries." |s| s := nil. self do: [:each | s := s ifNil: [each] ifNotNil: [each + s]]. ^s ifNil: [0] ifNotNil: [s]

On Tue, 24 Mar 2020 at 02:46, James Foster <smallt...@jgfoster.net> wrote: > > > > On Mar 23, 2020, at 6:06 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > > What you found out now is that the clever trick used to avoid picking an > > additive identity (picking an element, counting it twice and then > > subtracting it) leads to a loss of precision when floating point numbers > > are involved. This is an important issue. > > If this approach is to be preserved, then each class should have an additive > identity so instead of adding and subtracting an object, we let the object > tell us its zero. > > James