issue_comments
11 rows where issue = 224878728 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 · 11 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
656361865 | https://github.com/pydata/xarray/issues/1388#issuecomment-656361865 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDY1NjM2MTg2NQ== | dcherian 2448579 | 2020-07-09T21:32:52Z | 2020-07-09T21:32:52Z | MEMBER | I think this is fixed now thanks to @johnomotani |
{ "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 | |
571137508 | https://github.com/pydata/xarray/issues/1388#issuecomment-571137508 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDU3MTEzNzUwOA== | stale[bot] 26384082 | 2020-01-06T13:26:42Z | 2020-01-06T13:26:42Z | NONE | In order to maintain a list of currently relevant issues, we mark issues as stale after a period of inactivity If this issue remains relevant, please comment here or remove the |
{ "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 | |
363072151 | https://github.com/pydata/xarray/issues/1388#issuecomment-363072151 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDM2MzA3MjE1MQ== | gajomi 244887 | 2018-02-05T12:35:10Z | 2018-02-05T12:35:10Z | CONTRIBUTOR | @fujiisoup and @shoyer Really enlightening comments above. I think I am starting to get the dao of xarray a bit better :)
Agreed it would be nice to have a consistent and well reasoned rule for coordinate propagation in aggregation methods. I think a key point here, which gets brought up in your example is that it might make sense to have different subrules depending on the semantics of the operation. Functions like
Yeah, I felt a little dirty appending '_argmax'.
OK. I think I understand now why @fujiisoup proposed output a Dataset rather than an array. That's a natural syntax for getting the values from the indices.
+1 to dedicated adding more methods if needed, since I think even if it isn;t needed the associated docs will need to make sure users are aware of the analogous |
{ "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 | |
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 | |
362902669 | https://github.com/pydata/xarray/issues/1388#issuecomment-362902669 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDM2MjkwMjY2OQ== | fujiisoup 6815844 | 2018-02-04T12:20:33Z | 2018-02-04T12:52:29Z | MEMBER | @gajomi Sorry for my late response and thank you for the proposal. But aside from my previous proposal, I was thinking whether such aggregation methods (including Such specific rules may be confusing and bring additional complexity. I think the rule we do not track coordinates after aggregations would be much simpler and easier to understand. If we adopt the above rule, I think the In [4]: da.argmin(dim='x') Out[4]: <xarray.DataArray (y: 3)> array([0, 1, 0]) Coordinates: * y (y) <U1 'a' 'b' 'c' In [3]: da.isel(x=da.argmin(dim='x')) Out[3]: <xarray.DataArray (y: 3)> array([0, 1, 2]) Coordinates: x (y) int64 1 2 1 * y (y) <U1 'a' 'b' 'c' ``` I think your logic would be useful even we do not track the coordinate. I would appreciate any feedback. |
{ "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 | |
362717912 | https://github.com/pydata/xarray/issues/1388#issuecomment-362717912 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDM2MjcxNzkxMg== | gajomi 244887 | 2018-02-02T21:50:05Z | 2018-02-02T21:50:05Z | CONTRIBUTOR | I just came across the various argmax/idxmax (and related min) related issues recently in a project I have been working on. In addition to agreeing that docs should be updated when appropriate here are my two or three cents:
Coordinates: * w (w) <U3 'w_0' 'w_1' * x (x) <U3 'x_0' 'x_1' * y (y) <U3 'y_0' 'y_1' * z (z) <U3 'z_0' 'z_1' ``` I would like to get something like the following ```python
Coordinates:
* x (x) object 'x_0' 'x_1'
* z (z) object 'z_0' 'z_1'
* argmaxdim (argmaxdim) <U1 'w' 'y'
def argmax(da, dim=None): daname = "" if da.name is None else da.name name = daname+"_argmax" if dim is None: maxda = da.where(da == da.max(),drop=True) dims = list(maxda.dims) dimmaxvals = [maxda.coords[dim].values[0] for dim in dims] result = xr.DataArray(dimmaxvals, dims='argmaxdim', coords={'argmaxdim':dims}, name = name) return result else: if isinstance(dim,str): dim = [dim] keepdims = [d for d in da.dims if d not in dim] dastacked = da.stack(keepdims = keepdims) slices = [_argmaxstackeddim(dastacked,i) for i in range(len(dastacked.keepdims))] return xr.merge(slices)[name] ``` |
{ "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 | |
338397633 | https://github.com/pydata/xarray/issues/1388#issuecomment-338397633 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDMzODM5NzYzMw== | fujiisoup 6815844 | 2017-10-21T13:51:04Z | 2017-10-21T13:51:04Z | MEMBER | I am thinking again how (We discussed the name for this new method in #1469 but here I just use For example with a three dimensional array with The above proposal for ii (and iii) is not quite clean, as if it is used as an argument of Any thoughts are welcome. |
{ "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 | |
309280411 | https://github.com/pydata/xarray/issues/1388#issuecomment-309280411 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDMwOTI4MDQxMQ== | fujiisoup 6815844 | 2017-06-18T14:18:40Z | 2017-06-19T12:56:03Z | MEMBER | I'm working to fix this and I would like to make some design decisions;
Edit:
|
{ "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 | |
298253809 | https://github.com/pydata/xarray/issues/1388#issuecomment-298253809 | https://api.github.com/repos/pydata/xarray/issues/1388 | MDEyOklzc3VlQ29tbWVudDI5ODI1MzgwOQ== | lamorton 23484003 | 2017-04-30T20:08:25Z | 2017-04-30T20:08:25Z | NONE | Well, The next question is, what happens if you start supplying coordinate/dimension optional arguments to Does that seem reasonable? |
{ "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 6