html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/1288#issuecomment-359534363,https://api.github.com/repos/pydata/xarray/issues/1288,359534363,MDEyOklzc3VlQ29tbWVudDM1OTUzNDM2Mw==,1386642,2018-01-22T19:19:25Z,2018-01-22T19:19:25Z,CONTRIBUTOR,"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. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949
https://github.com/pydata/xarray/issues/1288#issuecomment-359521912,https://api.github.com/repos/pydata/xarray/issues/1288,359521912,MDEyOklzc3VlQ29tbWVudDM1OTUyMTkxMg==,244887,2018-01-22T18:38:50Z,2018-01-22T18:58:03Z,CONTRIBUTOR,">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.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949
https://github.com/pydata/xarray/issues/1288#issuecomment-287768014,https://api.github.com/repos/pydata/xarray/issues/1288,287768014,MDEyOklzc3VlQ29tbWVudDI4Nzc2ODAxNA==,1386642,2017-03-20T14:03:10Z,2017-03-20T14:03:10Z,CONTRIBUTOR,"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>
> .
>
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949
https://github.com/pydata/xarray/issues/1288#issuecomment-287673906,https://api.github.com/repos/pydata/xarray/issues/1288,287673906,MDEyOklzc3VlQ29tbWVudDI4NzY3MzkwNg==,1386642,2017-03-20T03:45:18Z,2017-03-20T03:45:18Z,CONTRIBUTOR,"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)

```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949
https://github.com/pydata/xarray/issues/1288#issuecomment-283158736,https://api.github.com/repos/pydata/xarray/issues/1288,283158736,MDEyOklzc3VlQ29tbWVudDI4MzE1ODczNg==,221526,2017-02-28T21:00:30Z,2017-02-28T21:00:30Z,CONTRIBUTOR,"👍  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.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949
https://github.com/pydata/xarray/issues/1288#issuecomment-283143896,https://api.github.com/repos/pydata/xarray/issues/1288,283143896,MDEyOklzc3VlQ29tbWVudDI4MzE0Mzg5Ng==,6200806,2017-02-28T19:52:23Z,2017-02-28T19:52:23Z,CONTRIBUTOR,I like the `integrate` idea.  Nothing further to add not already covered nicely via the above concerns by @rabernat and responses by @shoyer.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949