[Octave-bug-tracker] [bug #61143] Functions sum and mean returns wrong answer for single precision input

[Michael Leitner]

Follow-up Comment #19, bug #61143 (project octave):

Sorry, I just recognized that during writing what eventually became comment
#13 a large number of other comments were made. Thus, I mentioned points that
were introduced already earlier into the discussion.

Re comment #7: Of course no reordering can solve 

++
sum ([flintmax, 1])
--

However, this is because flintmax+1 cannot be represented. The initial report
here was about summing up many values of equal magnitude. If you do this
naively, then at some point you are doing flintmax+1, but there is no need to
do it like that. Kahan summation effectively corresponds to summing in
quadruple precision, and indeed, also this only works until it doesn't. For
pairwise summation, it is different: with this algorithm, you can sum realmax
(that is, more than 1e308) ones together and get the correct result, and the
failure is then again due to the inability to represent the result.

Re comment #11: Yes, we should be very concerned, but summing singles in
double precision does not cost anything in efficiency, and summing doubles by
pairwise summation should also cost very little. 

And re comment #18: the arguments are not really true. First, as I argued
above, it is not so much a question of representation as rather of the
summation algorithm. And the algorithm is not specified, neither in Octave nor
in Matlab (I think), so the only reasons to use the naive algorithm would be
less code and more efficiency (where the latter point is seemingly not valid).
No, as was shown in comment #5, summing 100e6 singles does not need to
overflow (in fact, overflow means something different). And no, it would not
be a bug if the summation of singles is performed in double precision and
therefore gives the arithmetically correct result, because, again, it is not
specified which algorithm is used. And I am very, very certain that users on
the whole would lose less time trying to understand the results of their code
if these results are closer to the arithmetically exact values rather than
farther away.

Concludingly, I would argue for using more accurate algorithms per default if
these do not cost noticeably in efficiency (and they are also not so hard to
implement), in particular for things like mean, where you cannot specify the
algorithm (and likely also won't be able to do in the future, as it has
already an optional string argument, which makes another optional string
argument very impractical).

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61143>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/