ENH: Implement IntegerArray.sum

[dsaxton]

• closes #xxxx
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

I think this is mostly interesting in that it allows normalize=True for value_counts on an IntegerArray backed Series, which currently doesn't work:

[ins] In [1]: s = pd.Series([1, 2, 3], dtype="Int64")

[ins] In [2]: s.value_counts(normalize=True)
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-2-2bf1a78353e5> in <module>
----> 1 s.value_counts(normalize=True)

~/pandas/pandas/core/base.py in value_counts(self, normalize, sort, ascending, bins, dropna)
   1252             normalize=normalize,
   1253             bins=bins,
-> 1254             dropna=dropna,
   1255         )
   1256         return result

~/pandas/pandas/core/algorithms.py in value_counts(values, sort, ascending, normalize, bins, dropna)
    725
    726     if normalize:
--> 727         result = result / float(counts.sum())
    728
    729     return result

AttributeError: 'IntegerArray' object has no attribute 'sum'

[jbrockmendel]

probably should make the signature match PandasArray.sum etc

[dsaxton]

Ok, and we still want to keep axis (even though it wouldn't be used here)?

[jbrockmendel]

is e.g. Series[Int64].sum() or DataFrame[Int64].sum() fixed by this?

[dsaxton]

Those are actually already working, just not for IntegerArray specifically

[jreback]

this is not the correct way to fix this. series/frames already dispatch to EAs via _reduce, which DO implement sum/prod/min/max. The issue is these functions need to be exposed via that dispatch mechanism, rather than writing more code to actually do the reduction.

[jreback]

furthermore the numpy_ EA do this in an opposite way, meaning that the ops themselves are defined, and _reduce dispatches TO them.

So we should decide on a single way forward here. I think the way integer array does this is better, e.g. in _reduce.

[jorisvandenbossche]

As mentioned in #33351 (comment), we should probably have a general discussion about how to deal with those reduction methods in our EAs, otherwise those comments like Jeff's concern above (#33538) are going to keep coming up in each PR that adds something like this.

[jorisvandenbossche]

Can you remove all those unnecessary keywords and put them in a **kwargs ?

[jreback]

lgtm. @jorisvandenbossche agree we agree on the issues you mentioned, but happy with this for now.

[jorisvandenbossche]

thanks @dsaxton !

[jorisvandenbossche]

@dsaxton would you like to open a general issue about this? (#33538 (comment))