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/1603#issuecomment-949485684,https://api.github.com/repos/pydata/xarray/issues/1603,949485684,IC_kwDOAMm_X844mAB0,38346144,2021-10-22T10:15:39Z,2021-10-22T10:15:39Z,NONE,So I think maintain the origin dims may do less broken on current code.,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,262642978
https://github.com/pydata/xarray/issues/1603#issuecomment-949484507,https://api.github.com/repos/pydata/xarray/issues/1603,949484507,IC_kwDOAMm_X844l_vb,38346144,2021-10-22T10:14:01Z,2021-10-22T10:14:01Z,NONE,"> For such case you could already do `ds.stack(z=(""t"", ""x"")).set_index(z=""C2"").sel(z=[""a"", ""e"", ""h""])`.
>
> After the explicit index refactor, we could imagine a custom index that supports multi-dimension coordinates such that you would only need to do something like
>
> ```python
> >>> S_res = S4.sel(C2=(""z"", [""a"", ""e"", ""h""]))
> >>> S_res
>
> Dimensions: (z: 3)
> Coordinates:
> * C2 (z) Data variables:
> A1 (z) float64 4 3 3
> ```
>
> or without explicitly providing the name of the packed dimension:
>
> ```python
> >>> S_res = S4.sel(C2=[""a"", ""e"", ""h""])
> >>> S_res
>
> Dimensions: (C2: 3)
> Coordinates:
> * C2 (C2) Data variables:
> A1 (C2) float64 4 3 3
> ```
well, both ""contain the origin dims"" or just ""generate another one"" have its benefit.
if we contain origin dims, we can ensure that:
- less difference between 1d coordinate and multi dims ones, both can run like S1.sel(C1=[""a"", ""e"", ""h""]) S4.sel(C2=[""a"", ""e"", ""h""]) and return a new data set with origin dims ( that's why I highly not recommended the implicit one )
- return a new data set have original dims which means if you change C1 to C2, and the rest code have S_res.sel(x=[1,2,3]) still work.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,262642978
https://github.com/pydata/xarray/issues/1603#issuecomment-949423480,https://api.github.com/repos/pydata/xarray/issues/1603,949423480,IC_kwDOAMm_X844lw14,38346144,2021-10-22T08:56:38Z,2021-10-22T09:15:17Z,NONE,"well, here are my ideas on how to define coordinates with multi dims.(because of github's bug, the characters of 1st image are white, I can not fix it)
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,262642978
https://github.com/pydata/xarray/issues/1603#issuecomment-949401881,https://api.github.com/repos/pydata/xarray/issues/1603,949401881,IC_kwDOAMm_X844lrkZ,38346144,2021-10-22T08:25:54Z,2021-10-22T08:25:54Z,NONE,"> Thanks for the detailed description @weipeng1999. For the first 4 slides I don't see how this is different from how does `S_res = S1.sel(C1=['a', 'b']` and `S_res = S2.sel(C1=['a', 'b'])` currently? And for the last 2 slides, I don't think that we always want such implicit broadcasting for dimensions that are not involved in the indexed coordinates.
thank you for figuring out the wrong things what I done. Well, it' is hard to explain the idea because it is a bit complicated, the last two picture is wrong and make misunderstanding, here are two images explain what I actuarily mean:
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,262642978
https://github.com/pydata/xarray/issues/1603#issuecomment-947480352,https://api.github.com/repos/pydata/xarray/issues/1603,947480352,IC_kwDOAMm_X844eWcg,38346144,2021-10-20T09:15:41Z,2021-10-20T09:15:41Z,NONE,"> Hi @weipeng1999,
>
> I'm not sure to fully understand your suggestion, would you mind sharing some illustrative examples?
>
> It is useful to have two distinct `coordinate variable` vs `data variable` concepts. Although both are data arrays, the former is used to locate data in the dimensional space(s) defined by all dimensions in the dataset while the latter is used to store field data.
>
> It also helps to have a clear separation between the `coordinate variable` and `index` concepts. An index is a specific data structure or object that allows efficient data extraction or alignment based one or more coordinate labels. Sometimes an index object may be handled like a data array (like pandas indexes) but this is not always the case (e.g., a KD-Tree).
>
> Currently in Xarray the `index` concept is hidden behind ""dimension"" coordinate variables. The goal of the explicit index refactor is to bring it to the light and make it available to _any_ coordinate (and also open it to custom index structures, not only pandas indexes).
>
> It looks like what you suggest is some kind of implicit (co-)indexes hidden behind any dataset variable(s)? We actually took the opposite direction, trying to make everything explicit.
Try to explain my idea, I make a PPT.
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,262642978
https://github.com/pydata/xarray/issues/1603#issuecomment-946337314,https://api.github.com/repos/pydata/xarray/issues/1603,946337314,IC_kwDOAMm_X844Z_Yi,38346144,2021-10-19T03:32:13Z,2021-10-19T03:33:54Z,NONE,"Well, maybe we can consider the coordinates in a more generic way.
### Let us define coordinate an array in data set cause co-indexed when we index its data set. It means that:
- If A1,A2,A3 are in a same data set S, we index S[ {'A1':I} ] will return a new data set which not only have indexed A1, but they also been Indexed that the A2 A3 which have dims shared with A1. This behavior I call it co-index.
### Use dims to determined the way how other array of the data set will be co-indexed.
- If all dims of A1(as coordinate) are also in A2(as regular array co-indexed), obviously the behavior can simply follow the old behavior, just change at the same dim and contain others.
- If A1 has a dim which not in A2, we should broadcast A2 at the dim, because the older behavior is to consider None dim as broadcast-able dim during other operation so co-index should follow it.
### Some compatibility issues:
- maybe need a New Type like DataArray but only have dims instead of both dims and coordinate
- just define how Dataset to deal with index, maybe DataArray is simlar.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,262642978