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-283162736,https://api.github.com/repos/pydata/xarray/issues/1288,283162736,MDEyOklzc3VlQ29tbWVudDI4MzE2MjczNg==,16630731,2017-02-28T21:15:39Z,2017-02-28T21:15:39Z,NONE,"> >  The issue is that certain types of gridded data (such as output from numerical models) should actually not be integrated with the trapezoidal rule but rather should use the native finite volume discretization for their computational grid. 

> * We are aiming for the 20% of functionality that covers 80% of use cases, not the long tail.
> * We don't want implementations of any complex numerical methods in xarray (like NumPy rather than SciPy).

I can see the problems down the road that @rabernat brings up.  Say you have a high-order finite volume discretization and some numerical implementation of high-order integration for that gridding.  What would your interface be?  You could write it as `new_integrate(da, dim, domain)` but then it may be confusing to have `da.integrate` be different (and less accurate).

That might bring us back to the algorithmically descriptive name `trapz`, but then what about @shoyer's point that given a fixed gridding, `da.integrate` is the most readable choice of name?  Perhaps allow generic extension of `da.integrate` by letting the `method` keyword of `da.integrate` accept a function as an argument that performs the actual integration?","{""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-282970673,https://api.github.com/repos/pydata/xarray/issues/1288,282970673,MDEyOklzc3VlQ29tbWVudDI4Mjk3MDY3Mw==,16630731,2017-02-28T08:07:49Z,2017-02-28T08:14:06Z,NONE,"An `integrate` method is probably better for the reason you describe---it's more obvious.  I believe the name `trapz` came from Matlab originally.  

With a general `integrate`, it's probably also useful to allow optional input arguments for `lower_bound` and `upper_bound`  as a convenience for integrating over a subset of the data instead of the user doing that in a slice.  If those arguments aren't given, they would default to all of the data.","{""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-282963661,https://api.github.com/repos/pydata/xarray/issues/1288,282963661,MDEyOklzc3VlQ29tbWVudDI4Mjk2MzY2MQ==,16630731,2017-02-28T07:28:54Z,2017-02-28T07:37:58Z,NONE,"I don't at the moment see a reason to use a different API than `DataArray.mean` or `DataArray.sum`.  DataArrays assume a default spacing of 1 if coordinates are not given, which is exactly what `np.trapz` does.  So the API for trapz might look like:

`DataArray.trapz(dim=None, axis=None, skipna=None, keep_attrs=False, **kwargs)`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,210704949