issue_comments

Is there a next step for a function which: - Is a drop-in replacement for .reduce - Similar to https://github.com/pydata/xarray/issues/1618, though maybe even simpler, i.e. only operates on a single input at first - Wraps apply_ufunc - Would restore dim order https://github.com/pydata/xarray/issues/1739 - Could be used by @fujiisoup 's recent functions, ref https://github.com/pydata/xarray/pull/2650#issuecomment-454164295 (though some of these may require multiple inputs, even though there's only one output?)

I'd be happy to give this a go if we agree on the broad design

For names, it's a shame the current apply isn't called map, and this could be apply. I'm not a great fan of apply_raw, since I'm can't yet see why it's any more 'raw'.

It's probably worth thinking about these APIs more systematically, see #1618, #1251, #1130

Nice, thanks for finding those

It might also be clearer to split this functionality into two methods rather than the single reduce() method, e.g., reduce() and transform() in the model of pandas's groupby methods.

Is the split needed? I had thought that the function either - returned a reduced array, and the output dims should be reduced - returned an array with the original dims, and then output dims shouldn't be reduced

It might also be clearer to split this functionality into two methods rather than the single reduce() method, e.g., reduce() and transform() in the model of pandas's groupby methods.

It's probably worth thinking about these APIs more systematically, see https://github.com/pydata/xarray/issues/1618, https://github.com/pydata/xarray/issues/1251, https://github.com/pydata/xarray/issues/1130

Is there a conceptual overlap between the goals of .reduce and apply_ufunc? I had initially thought that .reduce strictly reduced a dimension, though that's not actually the case given cumsum

Yes, I think so. reduce() is a simpler but complementary model to apply_ufunc.

Maybe we should rename reduce() to something like apply_axis_func() or apply_over_dim? I would use the name apply_along_axis but the numpy function of the same name does something different.

Thanks a lot for the comments @shoyer , that's v clarifying

Is there a conceptual overlap between the goals of .reduce and apply_ufunc? I had initially thought that .reduce strictly reduced a dimension, though that's not actually the case given cumsum

cc @fujiisoup

The challenge here is that this logic depends on the nature of the function. It only makes skip variables if applying the operation to a scalar returns the scalar. This is true for many but not all reductions, and there are lots of edge cases, e.g., - mean returns the same value, but integers should be cast to floats for consistency - sum returns the original element unless it's a scalar NaN (in which case it gets replaced by 0, unless skipna=False - count should always return 1, regardless of the original value - indexing does always return the same value

So this really needs to be opt-in only, and even then I'm not sure it's worth the trouble. It might be better to explicitly define functions even in the case of axis=() (the empty tuple), and either reuse the reduce() interface or make another (e.g., transform?) for functions that are oriented along a set of axes.

Actually, it isn't documented behavior but reduce() will already correctly handle this cases, too, e.g., for functions like cumsum() (this is used internally): ``` In [13]: ds = xarray.Dataset({'a': ('x', np.arange(3))})

In [14]: ds.reduce(np.cumsum) Out[14]: <xarray.Dataset> Dimensions: (x: 3) Dimensions without coordinates: x Data variables: a (x) int64 0 1 3 ```