issue_comments

I would also be very interested in seeing your codes @lamorton. Overall, I think the xarray community could really benefit from some kind of centralized contrib package which has a low barrier to entry for these kinds of functions. So far, I suspect there has been a large amount of code duplication for routine tasks like the fft, since I have also written a function for that.

I've written wrappers for svd, fft, psd, gradient, and specgram, for starts

@lamorton I really like the suggestion from @shoyer about submodules for throwing wrappers from other libraries, but in the meantime I think I might like very much to check out your implementation of fft and gradient in particular if these are somewhere public. I have been hacking at at least the latter and other functions in the numpy/scipy scope.

I usually agree that using too many (or any) switches within functions is not ideal. However, I think this is more important for low level or internal routines. For user facing interfaces, I think it is okay. After all, many numpy and scipy functions have convenient switches that control the return values.

By the way, the cumtrapz implementation I pasted above matches the scipy version when initial=0, which I also think would be a more sane default for integration.

As far as implementation is concerned. Is there any performance downside to using xarrays shift operators versus delving deeper into dask with map_blocks, etc? I looked into using dasks cumreduction function, but am not sure it is possible to implement the trapezoid method in that way without changing dask. On Mon, Mar 20, 2017 at 8:48 AM Fabien Maussion notifications@github.com wrote:

An argument against a single function is that the shape of the returned array is different in each case. Also, cumtrapz https://docs.scipy.org/doc/scipy-0.10.1/reference/generated/scipy.integrate.trapz.html has an inital keyword which changes the shape of the returned array. It is currently set to None per default, but should be set to 0 per default IMO.

I this is not a problem, I also like to have one single function for integration (simpler from a user perspective).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/issues/1288#issuecomment-287749414, or mute the thread https://github.com/notifications/unsubscribe-auth/ABUokrAdpysuufZxHdLSdc1nseH9PtOkks5rnnWYgaJpZM4MOCxc .

I would also like to see an integrate function. I have had one monkey patched in my own xarray routines for a while now. Also wanted: cumtrapz and friends. Maybe this could be implemented by adding an optional cumulative flag. This shouldn't be too hard to do. For example, in the following cumtrapz implementation all that would need to be changed is the final cumsum call.

```python def cumtrapz(A, dim): """Cumulative Simpson's rule (aka Tai's method)

Notes
-----
Simpson rule is given by
    int f (x) = sum (f_i+f_i+1) dx / 2
"""
x = A[dim]
dx = x - x.shift(**{dim:1})
dx = dx.fillna(0.0)
return ((A.shift(**{dim:1}) + A)*dx/2.0)\
      .fillna(0.0)\
      .cumsum(dim)

```

👍 for the functionality (both intergrate and gradient) that work with DataArray. My concern is that this doesn't feel like functionality that inherently belongs as a method on a DataArray--if doesn't need to be a method, it shouldn't be. In numpy and scipy, these are separate functions and I think they work fine that way.

Another way to look at it is that methods are there to encapsulate some kind of manipulation of internal state or to ensure that some kind of invariant is maintained. I don't see how integrate is doing any of this for DataArray--seems like everything integrate would do would be doing can be accomplished using the public API. So really what you're buying is doing this: python da.integrate(dim='x', method='trapezoidal') instead of python integrate(da, dim='x', method='trapezoidal`) If you want to see what the pathological case of putting everything as a method for convenience looks like, go look at all the plot methods on matplotlib's Axes class. Pay special attention to the tangled web of stuff that comes from having ready access to the class's internals.

My real preference would just to have this work: python ds = xr.tutorial.load_dataset('rasm') np.trapz(ds['Tair'], axis='x') but I have no idea what that would take, so I'm perfectly fine with xarray gaining its own implementation.

I like the integrate idea. Nothing further to add not already covered nicely via the above concerns by @rabernat and responses by @shoyer.