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/1388#issuecomment-656361865,https://api.github.com/repos/pydata/xarray/issues/1388,656361865,MDEyOklzc3VlQ29tbWVudDY1NjM2MTg2NQ==,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}",,224878728 https://github.com/pydata/xarray/issues/1388#issuecomment-571137508,https://api.github.com/repos/pydata/xarray/issues/1388,571137508,MDEyOklzc3VlQ29tbWVudDU3MTEzNzUwOA==,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 `stale` label; otherwise it will be marked as closed automatically ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,224878728 https://github.com/pydata/xarray/issues/1388#issuecomment-363072151,https://api.github.com/repos/pydata/xarray/issues/1388,363072151,MDEyOklzc3VlQ29tbWVudDM2MzA3MjE1MQ==,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 :) >I was thinking whether such aggregation methods (including argmin) should propagate the coordinate. 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 `argmax` are explicitly concerned with underlying ""indices"" (dimensions or otherwise) and so may call for different behavior from the `mean`, which explicitly is explicitly invariant under permutations of the underlying indices. The `max`/`min`/`median` functions are interesting case to think about, in that they are also invariant with under change of underlying indices, but can have potentially more than one index that they are associated with and do not ""destroy"" information about the value at those indices. >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) Yeah, I felt a little dirty appending '_argmax'. >I think my favorite option is (2) with da.argmin_indices() returning a Dataset, which will allow da[da.argmin_indices()] 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. >Either way, I would like a separate dedicated method for returning multiple indexing arrays. +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 `idx*` methods if they get added. ","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,224878728 https://github.com/pydata/xarray/issues/1388#issuecomment-362951129,https://api.github.com/repos/pydata/xarray/issues/1388,362951129,MDEyOklzc3VlQ29tbWVudDM2Mjk1MTEyOQ==,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 `min()` and `max()` methods, but I don't feel strongly about this. The exact coordinates could be surprising if there are multiple min/max values. 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., `argmaxdim` for keeping track of multiple indices. 2. Return a dict or Dataset with multiple indices. I think my favorite option is (2) with `da.argmin_indices()` returning a Dataset, which will allow `da[da.argmin_indices()]` to work after we finish switching `__iter__` to only iterate over data variables (https://github.com/pydata/xarray/issues/884#issuecomment-338445322). One downside of this approach is that it is not obvious how we woudl define `argmin_indices()` to work on a Dataset, but that's probably OK given that you cannot use a Dataset (yet) for indexing. 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 `idxmin()`, which might put indices of different dtypes in the same array. 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 `argmaxdim` or return a dict/Dataset for multiple dimensions, then we will end up with an annoying inconsistency between the 1D and N-D versions. It would be better to say `argmax(dim)` is only for one dimension (and raise an error if this is not true) and have the separate `argmax_indices(dims)` that is consistently defined for any number of dimensions.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,224878728 https://github.com/pydata/xarray/issues/1388#issuecomment-362902669,https://api.github.com/repos/pydata/xarray/issues/1388,362902669,MDEyOklzc3VlQ29tbWVudDM2MjkwMjY2OQ==,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 `argmin`) should propagate the coordinate. For example, as you pointed out, in theory, we may be able to track `x`-coordinate at the argmin index after `da.argmin(dim='x')`. But it is not reasonable for `da.mean(dim='x')`. It may be reasonable for `da.max(dim='x')` but not for `da.median(dim='x')`. 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 `argmin` would give just an array of indices, ```python In [1]: import xarray as xr ...: da = xr.DataArray([[0, 3, 2], [2, 1, 4]], dims=['x', 'y'], ...: coords={'x': [1, 2], 'y': ['a', 'b', 'c']}) ...: In [4]: da.argmin(dim='x') Out[4]: array([0, 1, 0]) Coordinates: * y (y) array([0, 1, 2]) Coordinates: x (y) int64 1 2 1 * y (y) >>da array([[[[ 0.149945, 0.230338], [ 0.626969, 0.299918]], [[ 0.351764, 0.286436], [ 0.130604, 0.982152]]], [[[ 0.262667, 0.950426], [ 0.76655 , 0.681631]], [[ 0.635468, 0.735071], [ 0.901116, 0.601303]]]]) Coordinates: * w (w) >>argmax(da) array(['w_0', 'x_1', 'y_1', 'z_1'], dtype='>>argmax(da, dim=list(""wy"")) array([[['w_1', 'y_1'], ['w_1', 'y_0']], [['w_1', 'y_1'], ['w_0', 'y_1']]], dtype=object) Coordinates: * x (x) object 'x_0' 'x_1' * z (z) object 'z_0' 'z_1' * argmaxdim (argmaxdim)