Skip to content
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

cumsum providing correct behavior for non-coordinate DataArrays? #1335

Open
pwolfram opened this issue Mar 28, 2017 · 5 comments
Open

cumsum providing correct behavior for non-coordinate DataArrays? #1335

pwolfram opened this issue Mar 28, 2017 · 5 comments

Comments

@pwolfram
Copy link
Contributor

In the case of a DataArray without coordinates, should cumsum work without specifying an axis, e.g., da.cumsum() is valid? This is not currently the obtained behavior.

In [1]: import xarray as xr
imp
In [2]: import numpy as np

In [3]: da = xr.DataArray(np.arange(10))

In [4]: da
Out[4]: 
<xarray.DataArray (dim_0: 10)>
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
Dimensions without coordinates: dim_0

In [5]: da.cumsum(axis=0)
Out[5]: 
<xarray.DataArray (dim_0: 10)>
array([ 0,  1,  3,  6, 10, 15, 21, 28, 36, 45])
Dimensions without coordinates: dim_0

In [6]: da.cumsum()
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-5-4ff0efc782ee> in <module>()
----> 1 da.cumsum()

/Users/pwolfram/src/xarray/xarray/core/common.pyc in wrapped_func(self, dim, axis, skipna, keep_attrs, **kwargs)
     17                              keep_attrs=False, **kwargs):
     18                 return self.reduce(func, dim, axis, keep_attrs=keep_attrs,
---> 19                                    skipna=skipna, allow_lazy=True, **kwargs)
     20         else:
     21             def wrapped_func(self, dim=None, axis=None, keep_attrs=False,

/Users/pwolfram/src/xarray/xarray/core/dataarray.pyc in reduce(self, func, dim, axis, keep_attrs, **kwargs)
   1146             summarized data and the indicated dimension(s) removed.
   1147         """
-> 1148         var = self.variable.reduce(func, dim, axis, keep_attrs, **kwargs)
   1149         return self._replace_maybe_drop_dims(var)
   1150 

/Users/pwolfram/src/xarray/xarray/core/variable.pyc in reduce(self, func, dim, axis, keep_attrs, allow_lazy, **kwargs)
    898             if dim is None and axis is None:
    899                 raise ValueError("must supply either single 'dim' or 'axis' "
--> 900                                  "argument to %s" % (func.__name__))
    901 
    902         if dim is not None:

ValueError: must supply either single 'dim' or 'axis' argument to cumsum
@fmaussion
Copy link
Member

I'm not sure that whether coordinates should play a role here, but rather the dimensionality of the data (i.e. maybe xarray could infer that the data has one dimension and work on that axis?).

I personally find the numpy behavior with ndarrays (flattening the array before applying cumsum) quite dangerous, I would rather like it to raise an error...

a = np.arange(12).reshape((4, 3))
np.cumsum(a)
array([ 0,  1,  3,  6, 10, 15, 21, 28, 36, 45, 55, 66])

@pwolfram
Copy link
Contributor Author

Thanks @fmaussion, it just seems strange that if the data is one-dimensional we return an error. I would agree that we probably want an error for dimensionality larger than one. I think the thing to change here is to make da.cumsum() work for one-dimensional da. But, it may not be worth the effort to fix this issue relative to other issues.

@shoyer
Copy link
Member

shoyer commented Mar 28, 2017

Yes, it would be reasonable to not require specifying the dimension for one-dimensional arguments.

I recall this coming up before for other methods, but can't remember the particulars now.

@shoyer
Copy link
Member

shoyer commented Mar 30, 2017

Someone also wanted a default dimension for diff: #1131

@stale
Copy link

stale bot commented Mar 1, 2019

In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity

If this issue remains relevant, please comment here or remove the stale label; otherwise it will be marked as closed automatically

@stale stale bot added the stale label Mar 1, 2019
@stale stale bot closed this as completed Mar 31, 2019
@shoyer shoyer reopened this Mar 31, 2019
@stale stale bot removed the stale label Mar 31, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants