BUG: Use -0. as initial value for summation

Technically, we should ensure that we do all summations starting with
-0 unless there is nothing to sum (in which case the result is clearly
0).
This is a start, since the initial value is still filled in as 0 by
the reduce machinery.  However, it fixes the odd case where an
inplace addition:

   x1 = np.array(-0.0)
   x2 = np.array(-0.0)
   x1 += x2

May go into the reduce code path (becaus strides are 0).  We could
avoid the reduce path there, but -0 here is strictly correct anyway
and also a necessary step towards fixing `sum([-0., -0., -0.])`
which still requires `initial=-0.0` to be passed manually right now.

There are new `xfail` marked tests also checking the path without
initial.  Presumably, we should be using -0.0 as initial value,
but 0.0 as default (if an array is empty) here.
This may be more reasonably possible after gh-20970.

Closes gh-21213, gh-21212

0 files changed, 0 insertions, 0 deletions