-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
API: Sparse Return Types #12855
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
these were all JUST fixed by @sinhrks if you would like to make a master documentation issue, pls do. but leave it as this one. |
ok, then if you find more things. just add them at the top, DONT't create more issues about this |
though this is actually not a documentation issue at all. but a functional one. |
@jreback : well at the very least, the documentation should be changed to match? |
@gfyoung ABOSOLUTEY NOT. Its an issue, you don't just change the documentation you fix the problem! |
I'm confused. We're currently providing incorrect information in the documentation...I meant this should be a temporary measure. |
@gfyoung how are you confused? its an api issue, changing the documentation (which is only inherited) is pointless. you can certainly propose a fix for the issue. fixing documentation is a band-aid which is not even worth doing. |
@jreback : If you had just said, "it's not worthwhile to change the documentation as a stopgap measure even though it is incorrect," instead of your last two comments, that would have cleared up my confusion. |
Looking at this issue again, I must say I find this >>> s = SparseArray([1, 2, 2, np.nan, 2, 2, np.nan], fill_value=2)
>>> s.sum()
9.0
>>> s.cumsum()
array([1., 3., 5., nan, nan, nan, nan]) I would have expected the following: array([1., 3., 5., nan, nan, 7.0, 9.0, nan]) EDIT: Same is true for @jreback , @jorisvandenbossche , @sinhrks : Thoughts? |
@gfyoung +1. We should make an agreement that
|
@sinhrks : I was about to implement a fix, but what is the meaning of >>> data = np.arange(10)
>>> s = SparseArray(data, fill_value=2)
>>> s.sum()
45
>>> s = SparseArray(data, fill_value=np.nan)
>>> s.sum()
45 IIUC, |
|
@sinhrks : Okay, so the sums should be the same? |
Yes, should be the same. |
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return SparseArray and SparseSeries for SparseArray.cumsum() and SparseSeries.cumsum() respectively, regardless of fill_value. Close pandas-devgh-12855.
Always return `SparseArray` and `SparseSeries` for `SparseArray.cumsum()` and `SparseSeries.cumsum()` respectively, regardless of `fill_value`. Closes pandas-dev#12855. Author: gfyoung <[email protected]> Closes pandas-dev#14771 from gfyoung/sparse-return-type and squashes the following commits: 83314fc [gfyoung] API: Return sparse objects always for cumsum
The documentation of
SparseArray.cumsum
says it returns aSeries
, but that is not the case:Given that
to_dense
now returnsself.values
and ignoresfill_value
, this current behaviour incumsum
seems illogical and should probably just returnSparseArray
regardless. At the very least though, I think a documentation fix is in order.EDIT: there is a similar issue with
SparseSeries
that should also be addressedThe text was updated successfully, but these errors were encountered: