Accuracy issues of sum() specialization for floats/complexes #122234
Description
Bug report
Bug description:
Unfortunately, #121176 was merged with a bug:
Lines 2749 to 2755 in e968121
L2751 lacks cs_add(). Sorry for that. Reproducer:
sum([2j, 1., 10E100, 1., -10E100]) (should be 2+2j). I'll provide a patch.
But maybe cases for integer arguments also should use compensated summation? E.g.:
Lines 2689 to 2698 in e968121
on L2694 (and use
PyLong_AsDouble()). An example:
>>> sum([1.0, 10E100, 1.0, -10E100])
2.0
>>> sum([1.0, 10**100, 1.0, -10**100]) # huh?
0.0I would guess, that integer values in this case are treated as exact and they are allowed to smash floating-point result to garbage. But... This looks as a bug for me. fsum() also chooses 2.0:
>>> math.fsum([1.0, 10**100, 1.0, -10**100])
2.0CPython versions tested on:
CPython main branch
Operating systems tested on:
No response