GH-100425: Improve accuracy of builtin sum() for float inputs

[rhettinger]

• Issue: Improve accuracy of builtin sum() for float inputs #100425

[tim-one]

Why check for c being zero? Seems that unconditionally adding 0.0 (if it is 0) to f_result would be cheap and harmless.

[mdickinson]

Why check for c being zero?

It does avoid losing the sign on a negative zero result:

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

Admittedly that's a fairly niche corner case; I could live with the behaviour changing.

Thinking about corner cases, the compensation is also going to interfere with infinities and overflow. On this branch:

>>> sum([float("inf"), float("inf")])
nan
>>> sum([1e308, 1e308])
nan

But on main we get infinities as expected:

>>> sum([float("inf"), float("inf")])
inf
>>> sum([1e308, 1e308])
inf

We should try to keep the existing behaviour here. I think it should just be a matter of not adding the correction if it's an infinity or nan.

[rhettinger]

In commit 88bdb92 in 2019, Serhiy added these tests:

    self.assertEqual(repr(sum([-0.0])), '0.0')
    self.assertEqual(repr(sum([-0.0], -0.0)), '-0.0')
    self.assertEqual(repr(sum([], -0.0)), '-0.0')

It looks like he thinks there should be an invariant that sign of the start value should be preserved when iterable sum is equal to zero or empty. This seems dubious to me, but I rolled with it and added the "if (c)" test to preserve the invariant.

[mdickinson]

I don't think it's dubious: it's consistent with IEEE 754 rules that (under the default ties-to-even rounding mode) a sum of negative zeros is negative zero. It only affects the case where both the sum and the start value are negative zero; if the sum is positive zero it has no effect:

>>> sum([0.0], start=-0.0)  # same as (-0.0) + 0.0
0.0
>>> sum([-0.0], start=-0.0)  # should be the same as (-0.0) + (-0.0)
-0.0

[tim-one]

there should be an invariant that sign of the start value should be preserve

That's fine - but surely something so excruciatingly obscure deserves a comment 😜 .

[rhettinger]

We should try to keep the existing behaviour here. I think it should just be a matter of not adding the correction if it's an infinity or nan.

Done.

That's fine - but surely something so excruciatingly obscure deserves a comment

Done.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @rhettinger for commit 4da0b8f 🤖

If you want to schedule another build, you need to add the :hammer: test-with-buildbots label again.