issue_comments
3 rows where issue = 224878728 and user = 1217238 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: created_at (date), updated_at (date)
issue 1
- argmin / argmax behavior doesn't match documentation · 3 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
362951129 | https://github.com/pydata/xarray/issues/1388#issuecomment-362951129 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDM2Mjk1MTEyOQ== | shoyer 1217238 | 2018-02-04T23:54:10Z | 2018-02-04T23:54:10Z | MEMBER | I think it would be fine to add a special case to preserve coordinates corresponding to min/max values with xarray's I agree that it does not make sense to preserve coordinates along aggregated dimensions for argmin/argmax, but we can preserve other coordinates. So I like @fujiisoup's example behavior above. I suppose we now have two candidate APIs for returning multiple indices from a method like argmin/argmax:
1. Add an additional dimension, e.g., I think my favorite option is (2) with My concern with adding an additional dimension is that it is always a little surprising and error-prone when we invent new dimension names not supplied by the user (for example, this can lead to conflicting names). Also, consolidating indices will not work as well with Either way, I would like a separate dedicated method for returning multiple indexing arrays. It's convenient (and what users expect) for argmax to return a single array if taking the max only over one dimension. However, if we switch to add an |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
argmin / argmax behavior doesn't match documentation 224878728 | |
298256260 | https://github.com/pydata/xarray/issues/1388#issuecomment-298256260 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDI5ODI1NjI2MA== | shoyer 1217238 | 2017-04-30T20:50:49Z | 2017-04-30T20:50:49Z | MEMBER | I agree that The main downside of returning a tuple or dict from
|
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
argmin / argmax behavior doesn't match documentation 224878728 | |
297845435 | https://github.com/pydata/xarray/issues/1388#issuecomment-297845435 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDI5Nzg0NTQzNQ== | shoyer 1217238 | 2017-04-27T21:33:06Z | 2017-04-27T21:33:06Z | MEMBER | Agreed, the current implementation of |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
argmin / argmax behavior doesn't match documentation 224878728 |
Advanced export
JSON shape: default, array, newline-delimited, object
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]);
user 1