home / github / issue_comments

Menu
  • GraphQL API
  • Search all tables

issue_comments: 283109247

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-283109247 https://api.github.com/repos/pydata/xarray/issues/1288 283109247 MDEyOklzc3VlQ29tbWVudDI4MzEwOTI0Nw== 1217238 2017-02-28T17:34:05Z 2017-02-28T19:00:00Z MEMBER

As usual @rabernat raises some excellent points!

I weakly prefer not to use the name integrate and instead keep the standard scipy names because they make clear the numerical algorithm that is being applied.

Yes, this is a totally valid concern, if a user might expect integrate to be calculating something different.

One point in favor of calling this integrate is that the name is highly searchable, which provides an excellent place to include documentation about how to integrate in general (including links to other packages, like pangeo's vector calculus package). But we know that nobody reads documentation ;).

But where does it end? Why not implement the rest of the scipy.ode module?

Looking at the rest of scipy.integrate, in some ways the functionality of trapz/cumtrapz/simps is uniquely well suited for xarray: they are focused on data ("given fixed samples") rather than solving a system of equations ("given a function").

numpy.gradient feels very complementary as well, so I could see that as also in scope, but there are similar concerns for the name. There might be some value in complementary names for integrals/gradients.

As a community we need to develop a roadmap that clearly defines the scope of xarray.

I doubt we'll be able to come up with hard and fast rules, but maybe we can enumerate some principles, e.g.,

  • Features should be useful to users in multiple fields.
  • Features should be primarily about working with labeled data.
  • 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).
  • Sometimes it's OK to include a feature in xarray because it makes logical sense with the rest of the package even if it's slightly domain specific (e.g., CF-conventions for netCDF files).
{
    "total_count": 2,
    "+1": 2,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  210704949
Powered by Datasette · Queries took 1.135ms · About: xarray-datasette