home / github

Menu
  • Search all tables
  • GraphQL API

issue_comments

Table actions
  • GraphQL API for issue_comments

4 rows where author_association = "CONTRIBUTOR" and issue = 217385961 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

user 3

  • pwolfram 2
  • spencerahill 1
  • tomchor 1

issue 1

  • Shape preserving `diff` via new keywords · 4 ✖

author_association 1

  • CONTRIBUTOR · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
418154705 https://github.com/pydata/xarray/issues/1332#issuecomment-418154705 https://api.github.com/repos/pydata/xarray/issues/1332 MDEyOklzc3VlQ29tbWVudDQxODE1NDcwNQ== tomchor 13205162 2018-09-03T16:14:46Z 2018-09-03T16:14:46Z CONTRIBUTOR

I'm not sure where we stand on this issue, but I think since numpy.gradient already exists, it makes more sense to wrap that function for the sake of simplicity instead of making xr.diff differ from the original premise of np.diff.

On the same topic, it bothers me that xr.diff only accepts "upper" and "lower" arguments for the label. The most obvious (and useful) value in my opinion would be "middle", which would correspond to a centered finite differences. Is there any special reason why that option isn't there?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Shape preserving `diff` via new keywords 217385961
289855515 https://github.com/pydata/xarray/issues/1332#issuecomment-289855515 https://api.github.com/repos/pydata/xarray/issues/1332 MDEyOklzc3VlQ29tbWVudDI4OTg1NTUxNQ== spencerahill 6200806 2017-03-28T18:06:41Z 2017-03-28T18:06:41Z CONTRIBUTOR

I'm not sure we want to wrap np.gradient. It seems like other approaches like @rabernat 's xgcm would be more appropriate as a superset of xarray.

Certainly grid-aware differencing and integral operators are preferred when the grid information is known and available, but I'm not sure that therefore a more naive version akin to np.gradient would not be useful. It's quite likely that there are xarray users (e.g. in non climate/weather/ocean-related fields) wherein a 'c' grid is meaningless to them, yet they still would appreciate being able to easily compute derivatives via xarray operations.

But then we're back to the valid questions raised before re: what is the appropriate scope of xarray functionality, c.f. https://github.com/pydata/xarray/issues/1288#issuecomment-283062107 and subsequent in that thread

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Shape preserving `diff` via new keywords 217385961
289840161 https://github.com/pydata/xarray/issues/1332#issuecomment-289840161 https://api.github.com/repos/pydata/xarray/issues/1332 MDEyOklzc3VlQ29tbWVudDI4OTg0MDE2MQ== pwolfram 4295853 2017-03-28T17:14:29Z 2017-03-28T17:14:29Z CONTRIBUTOR

@rabernat, do you think that the proposed keyword additions should be included in xarray or not? I personally would like to see them in xarray but don't know if it is just me or not. If you think they should be in xarray, are you ok with the api above?

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Shape preserving `diff` via new keywords 217385961
289833779 https://github.com/pydata/xarray/issues/1332#issuecomment-289833779 https://api.github.com/repos/pydata/xarray/issues/1332 MDEyOklzc3VlQ29tbWVudDI4OTgzMzc3OQ== pwolfram 4295853 2017-03-28T16:52:25Z 2017-03-28T16:52:25Z CONTRIBUTOR

@shoyer, I'm not sure we want to wrap np.gradient. It seems like other approaches like @rabernat 's xgcm would be more appropriate as a superset of xarray.

Fundamentally, I want something that is like an inverse of cumsum and the proposed change could be used in that context. It is just super inconvenient to do array resizing following the diff of a time vector to get timesteps, but maybe this use case is too niche to be useful for the community.

{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
  Shape preserving `diff` via new keywords 217385961

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);
Powered by Datasette · Queries took 135.683ms · About: xarray-datasette