home / github / issue_comments

Menu
  • Search all tables
  • GraphQL API

issue_comments: 283158736

This data as json

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-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
Powered by Datasette · Queries took 79.7ms · About: xarray-datasette