This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: sum() incorrect on negative zeros
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.6, Python 3.5, Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Jim.Jewett, abarry, eric.smith, ethan.furman, lemburg, mark.dickinson, pitrou, rhettinger, stutzbach
Priority: low Keywords:

Created on 2016-02-10 00:08 by pitrou, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (8)
msg259961 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2016-02-10 00:08
>>> sum([-0.0,-0.0])
msg259962 - (view) Author: Anilyka Barry (abarry) * (Python triager) Date: 2016-02-10 00:13
This is consistent with the advertised equivalence of sum():

>>> -0.0 + -0.0 + 0

This works as you'd expect:

>>> sum([-0.0, -0.0], -0.0)

It has a start value of 0, and I don't think we should special-case this.
msg259963 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2016-02-10 00:15
"Expect" is a strong word here ;-) The problem is the start value is implicit and is supposed to be a "good default". Of course, solving this consistently may not be trivial.
msg259964 - (view) Author: Anilyka Barry (abarry) * (Python triager) Date: 2016-02-10 00:22
"Not trivial" might be an understatement. You need the start value to begin summing the items, but you may face with a non-repeatable generator with side-effects. Sure, you could special-case some builtins, but I'm not too keen on adding special cases for such an uncommon case. Feel free to prove me wrong, though!
msg259965 - (view) Author: Ethan Furman (ethan.furman) * (Python committer) Date: 2016-02-10 01:02
If one is using sum on floats, and a list of -0.0's is a possibility, and the sign matters... well, I would hope that one is using -0.0 as the start value.

I don't think this is worth "fixing".
msg259985 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2016-02-10 06:50
For what it's worth, NumPy has exactly the same behaviour:

>>> np.array([-0.0, -0.0]).sum()

... which is a bit surprising, given that this is a much easier problem to fix when you know the type of everything in the array in advance.

The Decimal type has similar issues here, resulting from that implicit addition of 0:

>>> from decimal import Decimal, getcontext
>>> getcontext().prec = 5
>>> x = Decimal('3.1415926535893')
>>> sum([x])

Fixing this would involve major changes to the way that sum works, or some horrible DWIM special-casing; I think it's best left as it is.
msg259986 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2016-02-10 06:51
> I think it's best left as it is

I concur.
msg260056 - (view) Author: Jim Jewett (Jim.Jewett) * (Python triager) Date: 2016-02-10 23:05
Even if Ethan's argument about an explicit start value were not convincing, Mark + Raymond would count as authoritative for floats.

Anyone can reopen if needed; I just don't want the issue to languish forever if there is at least grudging agreement.
Date User Action Args
2022-04-11 14:58:27adminsetgithub: 70512
2016-02-10 23:05:18Jim.Jewettsetstatus: open -> closed

nosy: + Jim.Jewett
messages: + msg260056

resolution: not a bug
2016-02-10 06:51:57rhettingersetnosy: + rhettinger
messages: + msg259986
2016-02-10 06:50:31mark.dickinsonsetmessages: + msg259985
2016-02-10 01:02:25ethan.furmansetnosy: + ethan.furman
messages: + msg259965
2016-02-10 00:22:21abarrysetmessages: + msg259964
2016-02-10 00:15:50pitrousetmessages: + msg259963
2016-02-10 00:13:31abarrysetnosy: + abarry
messages: + msg259962
2016-02-10 00:08:02pitroucreate