Repository navigation
Accuracy issues of sum() specialization for floats/complexes #122234
Copy link
Copy link
Closed
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Description
Bug report
Bug description:
Unfortunately, #121176 was merged with a bug:
Lines 2749 to 2755 in e968121
| if (PyFloat_Check(item)) { | |
| double value = PyFloat_AS_DOUBLE(item); | |
| re_sum.hi += value; | |
| im_sum.hi += 0.0; | |
| _Py_DECREF_SPECIALIZED(item, _PyFloat_ExactDealloc); | |
| continue; | |
| } |
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
| if (PyLong_Check(item)) { | |
| long value; | |
| int overflow; | |
| value = PyLong_AsLongAndOverflow(item, &overflow); | |
| if (!overflow) { | |
| re_sum.hi += (double)value; | |
| Py_DECREF(item); | |
| continue; | |
| } | |
| } |
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
Linked PRs
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
Activity
skirpichev commentedon Jul 24, 2024
CC @rhettinger for the second part (integer values). Is this an issue or a feature?
picnixz commentedon Jul 24, 2024
Actually, even without the
sum, we have:skirpichev commentedon Jul 24, 2024
@picnixz, that's a feature.
Ok, it seems that in the second case PyLong_AsLongAndOverflow() just overflows and we fallback to the generic sum. That's something copied from the specialization for integers (in 8ce8a78) and it wasn't changed in #100426. Maybe it should?
skirpichev commentedon Jul 24, 2024
Hmm, with PyLong_AsDouble() + compensated summation it's even faster!
while in the main:
pythongh-122234: fix accuracy issues for sum()
skirpichev commentedon Jul 24, 2024
PR is ready for review: #122236
It combines fixes for floats and integers. If second case requires more discussion or is "a feature", I can quickly revert that part.
gh-122234: fix accuracy issues for sum() (#122236)
pythongh-122234: Add DECREFs to error paths
encukou commentedon Jul 29, 2024
The added error returns leak references. This was caught by the noGIL refleak buildbot (which runs more often than refleaks for regular-builds): https://buildbot.python.org/#/builders/1226/builds/2352/steps/6/logs/stdio
Eclips4 commentedon Jul 29, 2024
PR is ready: #122405
encukou commentedon Jul 29, 2024
My PR #122406 looks exactly the same :)
IMO, it's better to associate the PR with this issue, so the fix-up PR is kept together with the original.
gh-122234: Add DECREFs to error paths (#122406)
picnixz commentedon Jul 29, 2024
Closing since the refleak is now fixed.