What's wrong with this definition?
      "(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 := 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

Reply via email to