{"action":"created","issue":{"url":"https://api.github.com/repos/pydata/xarray/issues/1017","repository_url":"https://api.github.com/repos/pydata/xarray","labels_url":"https://api.github.com/repos/pydata/xarray/issues/1017/labels{/name}","comments_url":"https://api.github.com/repos/pydata/xarray/issues/1017/comments","events_url":"https://api.github.com/repos/pydata/xarray/issues/1017/events","html_url":"https://github.com/pydata/xarray/pull/1017","id":179052741,"number":1017,"title":"WIP: Optional indexes (no more default coordinates given by range(n))","user":{"login":"shoyer","id":1217238,"avatar_url":"https://avatars.githubusercontent.com/u/1217238?v=3","gravatar_id":"","url":"https://api.github.com/users/shoyer","html_url":"https://github.com/shoyer","followers_url":"https://api.github.com/users/shoyer/followers","following_url":"https://api.github.com/users/shoyer/following{/other_user}","gists_url":"https://api.github.com/users/shoyer/gists{/gist_id}","starred_url":"https://api.github.com/users/shoyer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shoyer/subscriptions","organizations_url":"https://api.github.com/users/shoyer/orgs","repos_url":"https://api.github.com/users/shoyer/repos","events_url":"https://api.github.com/users/shoyer/events{/privacy}","received_events_url":"https://api.github.com/users/shoyer/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":14,"created_at":"2016-09-24T21:24:39Z","updated_at":"2016-10-19T14:45:25Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/pydata/xarray/pulls/1017","html_url":"https://github.com/pydata/xarray/pull/1017","diff_url":"https://github.com/pydata/xarray/pull/1017.diff","patch_url":"https://github.com/pydata/xarray/pull/1017.patch"},"body":"Fixes #283\r\n\r\nCurrently, when a Dataset or DataArray is created without explicit coordinate labels for a dimension, we insert a coordinate with the values given by range(n).\r\n\r\nThis is problematic, for two main reasons:\r\n\r\n1. There aren't always meaningful dimension labels. For example, an RGB image might represented by a DataArray with three dimensions ('row', 'column', 'channel'). 'row' and 'column' each have fixed size, but only channel has meaningful labels ['red', 'green', 'blue'].\r\n2. Default labels lead to bad default alignment behavior. In the RGB image example, when I combine a 200x200 pixel image with a 300x300 pixel image, xarray would currently align rows and columns into a 200x200 image. This isn't desirable -- you'd rather get an error than use default labels for alignment.\r\n\r\nAs is, xarray isn't a good fit for users who don't have meaningful coordinate labels over one or more dimensions. So making labels optional would also increase the audience for the project.\r\n\r\nIn general, I have followed the alignment rules I suggested for pandas in https://github.com/pydata/pandas-design/issues/17, but there are still some xarray specific design decisions to resolve:\r\n- [x] ~~How to handle `stack(z=['x', 'y'])` when one or more of the original dimensions do not have labels. If we don't insert dummy indexes for MultiIndex levels, then we can't unstack properly anymore.~~ Decision: insert dummy dimensions with `stack()` as necessary.\r\n- [x] ~~How to handle missing indexes in `.sel`, e.g., `array.sel(x=0)` when `x` is not in `array.coords`. In the current version of this PR, this errors, but my current inclination is to pass `.sel` indexers directly on to `.isel`, without remapping labels. This has the bonus of preserving the current behavior for indexing.~~ Decision: if a dimension does not have an associated coordinate, indexing along that dimension with `.sel` or `.loc` is positional (like `.isel`). \r\n- [ ] Should we create dummy/virtual coordinates like `range(n)` on demand when indexing a dimension without labels? e.g., `array.coords['x']` would return a DataArray with values `range(n)` (importantly, this would not change the original `array`).\r\n- [ ] What should the new behavior for `reindex_like` be, if the argument has dimensions of different sizes but no dimension labels? Should we raise an error, or simply ignore these dimensions?\r\n- [ ] What does the transition to this behavior look like? Do we simply add it to v0.9.0 with a big warning about backwards compatibility, or do we need to go through some sort of deprecation cycle with the current behavior?\r\n\r\nExamples of new behavior:\r\n```\r\nIn [1]: import xarray as xr\r\n\r\nIn [2]: a = xr.DataArray([1, 2, 3], dims='x')\r\n\r\nIn [3]: b = xr.DataArray([[1, 2], [3, 4], [5, 6]], dims=['x', 'y'], coords={'y': ['a', 'b']})\r\n\r\nIn [4]: a\r\nOut[4]:\r\n<xarray.DataArray (x: 3)>\r\narray([1, 2, 3])\r\n\r\nIn [5]: b\r\nOut[5]:\r\n<xarray.DataArray (x: 3, y: 2)>\r\narray([[1, 2],\r\n       [3, 4],\r\n       [5, 6]])\r\nCoordinates:\r\n  * y        (y) <U1 'a' 'b'\r\n\r\nIn [6]: a + b\r\nOut[6]:\r\n<xarray.DataArray (x: 3, y: 2)>\r\narray([[2, 3],\r\n       [5, 6],\r\n       [8, 9]])\r\nCoordinates:\r\n  * y        (y) <U1 'a' 'b'\r\n\r\nIn [7]: c = xr.DataArray([1, 2], dims='x')\r\n\r\nIn [8]: a + c\r\nValueError: dimension 'x' without indexes cannot be aligned because it has different sizes: {2, 3}\r\n\r\nIn [9]: d = xr.DataArray([1, 2, 3], coords={'x': [10, 20, 30]}, dims='x')\r\n\r\n# indexes are copied from the argument with labels if they have the same size\r\nIn [10]: a + d\r\nOut[10]:\r\n<xarray.DataArray (x: 3)>\r\narray([2, 4, 6])\r\nCoordinates:\r\n  * x        (x) int64 10 20 30\r\n```\r\n\r\nSo far, this PR is mostly for the sake of having something concrete to discuss. Obviously it's not ready to merge given that it has over 100 failing tests!"},"comment":{"url":"https://api.github.com/repos/pydata/xarray/issues/comments/254834925","html_url":"https://github.com/pydata/xarray/pull/1017#issuecomment-254834925","issue_url":"https://api.github.com/repos/pydata/xarray/issues/1017","id":254834925,"user":{"login":"shoyer","id":1217238,"avatar_url":"https://avatars.githubusercontent.com/u/1217238?v=3","gravatar_id":"","url":"https://api.github.com/users/shoyer","html_url":"https://github.com/shoyer","followers_url":"https://api.github.com/users/shoyer/followers","following_url":"https://api.github.com/users/shoyer/following{/other_user}","gists_url":"https://api.github.com/users/shoyer/gists{/gist_id}","starred_url":"https://api.github.com/users/shoyer/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/shoyer/subscriptions","organizations_url":"https://api.github.com/users/shoyer/orgs","repos_url":"https://api.github.com/users/shoyer/repos","events_url":"https://api.github.com/users/shoyer/events{/privacy}","received_events_url":"https://api.github.com/users/shoyer/received_events","type":"User","site_admin":false},"created_at":"2016-10-19T14:45:25Z","updated_at":"2016-10-19T14:45:25Z","body":"> I have never encountered this case yet but ignoring that dimension seems like a bad idea to me. When I use a.reindex_like(b), I usually mean \"make a compatible with b\", so I assume the resulting index and shape is the same than (or at least compatible with) b. More importantly, I expect to be able to do binary operations between the re-indexed a and b. \r\n\r\n@gdementen thanks for the input. I am inclined to agree. Even within the xarray codebase, we basically use `x = y.reindex_like(z)` as cleaner spelling for `x, _ = align(y, z, join='left')`.\r\n\r\n> Given that, I would go with either an error, or treat the missing index like it was range() in this case, ie fill the extra values with NAN.\r\n\r\nI think we want the error here, given that this is one of the major motivations for allowing missing coordinate labels (not assuming invalid labels)."}}
{"actor":{"display_login":"shoyer"}}