I’m interested in exploring this - partly because it hit me and wasted my time
chasing down why we have a difference in #sum from other languages. It seems
that the implementation is trying to be very clever - I guess from the generic
usage of collections which don’t have to contain only numbers.
The kicker for me (from below), was that its not obvious that the #average of a
collection of floats loses precision due to #sum.
For me, the generic case is numbers - and looking at senders of #sum they all
seem to be expecting numeric summation. So why wouldn’t we put the onus on
generic summation back on the caller (I’m assuming checking the collection
internally is too expensive to do it automatically?).
If we were to adjust #sum with the implementation of #sumNumbers, and then
introduce a new method #sumObjects (and forward #sumNumbers to #sum for partial
compatibility ) would all the test cases in the image catch this and give an
indication of the consequences?
Could we even consider such a change? Its brave - but shouldn’t Pharo behave
like you would expect (or am I missing an obvious use case).
Tim
> On 20 Mar 2020, at 15:24, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
> Thanks for sharing, this is indeed something quite subtle.
>
>> On 20 Mar 2020, at 16:19, Tim Mackinnon <tim@testit.works> wrote:
>>
>> Actually I can answer my own question - its the difference between #sum and
>> #sumNumbers (and an easy mistake to make - I almost wish that sum was the
>> sumNumbers implementation and there was a sumSample that behaved like now)
>
> There was a *LOT* of debate about that (especially that #() sum isZero).
>
> I also would would prefer #sum to be like you describe.
>
>>> On 20 Mar 2020, at 14:52, Tim Mackinnon <tim@testit.works> wrote:
>>>
>>> Hi guys - I recall this came up a few months ago, but I’m curious about the
>>> difference of Pharo’s use of Float64 vs Python - as I assumed that if
>>> languages use the same IEEE spec (or whatever spec it is) that simple stuff
>>> would be quite similar.
>>>
>>> I am curious why in Python adding these numbers:
>>>
>>> y = 987.9504418944 + 815.2627636718801 + 1099.3898999037601 +
>>> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 +
>>> 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 +
>>> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 +
>>> 784.5488305664002 + 957.3522631840398 + 1001.7526196294
>>> print(y)
>>> print(y / 15)
>>>
>>> Gives:
>>>
>>> 14832.682458496522
>>> 988.8454972331015
>>>
>>> In pharo I have noticed an anomaly which I thought was precision but it may
>>> be something odd with iterators.
>>>
>>> y := 987.9504418944 + 815.2627636718801 + 1099.3898999037601 +
>>> 1021.6996069333198 + 1019.8750146478401 + 1084.5603759764 +
>>> 1008.2985131833999 + 1194.9564575200002 + 893.9680444336799 +
>>> 1032.85460449136 + 905.9324633786798 + 1024.2805590819598 +
>>> 784.5488305664002 + 957.3522631840398 + 1001.7526196294.
>>> y.
>>> y / 15.
>>>
>>>
>>> Gives the same as Python.
>>>
>>>
>>> BUT:
>>>
>>> z := {987.9504418944 . 815.2627636718801 . 1099.3898999037601 .
>>> 1021.6996069333198 . 1019.8750146478401 . 1084.5603759764 .
>>> 1008.2985131833999 . 1194.9564575200002 . 893.9680444336799 .
>>> 1032.85460449136 . 905.9324633786798 . 1024.2805590819598 .
>>> 784.5488305664002 . 957.3522631840398 . 1001.7526196294} sum.
>>> z.
>>> z / 15.
>>>
>>>
>>> Gives
>>> 14832.68245849652
>>> 988.8454972331014
>>>
>>> Is this correct?
>>>
>>>
>>
>
>
