Thanks for the git issue - and sadly this goes back a long way :( I’ve added my example to the sad history… is there anyone that can rule on this?
> On 23 Mar 2020, at 21:23, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > https://github.com/pharo-project/pharo/issues/2225 > >> On 23 Mar 2020, at 17:14, Tim Mackinnon <tim@testit.works> wrote: >> >> I’m always impressed with the quality of answers that come out of these >> discussions - inevitably I’m reminded that dispatching off the right parties >> is ultimately where the power lies (when you cheat - it always seems to end >> up with a gotcha). >> >> Thanks guys. >> >> Tim >> >>> On 23 Mar 2020, at 15:15, James Foster <smallt...@jgfoster.net> wrote: >>> >>> >>>> On Mar 23, 2020, at 8:14 AM, Sven Van Caekenberghe <s...@stfx.eu> wrote: >>>> >>>> Both are excellent suggestions. >>>> >>>> We have to think a bit about the consequences. >>>> >>>> Still, both would not solve the problem of what to return when the >>>> collection is empty. >>> >>> Zero? >>> >>>> >>>>> On 23 Mar 2020, at 15:47, Konrad Hinsen <konrad.hin...@fastmail.net> >>>>> wrote: >>>>> >>>>> Am 23.03.20 um 14:45 schrieb James Foster: >>>>> >>>>>>> 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. >>>>> >>>>> Or define a singleton class "Zero" with a + method that returns the other >>>>> operand, and use that Zero object for the additive identity. >>>>> >>>>> Konrad. >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > >
