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/6573#issuecomment-1260551056,https://api.github.com/repos/pydata/xarray/issues/6573,1260551056,IC_kwDOAMm_X85LInuQ,4160723,2022-09-28T08:17:09Z,2022-09-28T08:17:09Z,MEMBER,"I also like the idea of alignment with some tolerance. There is an open PR #4489, which needs to be reworked in the context of the explicit index refactor.
Alternatively to a new kwarg we could add an index build option, e.g., `ds.set_xindex(""x"", index_cls=PandasIndex, align_tolerance=1e-6)`, but then it is not obvious how to handle different tolerance values given for the indexes to compare. Maybe this could depend on the given `join` method? E.g., pick the smallest tolerance for join=inner, the largest for join=outer, the tolerance of the left index for join=left, etc.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1226272301
https://github.com/pydata/xarray/issues/6573#issuecomment-1119082834,https://api.github.com/repos/pydata/xarray/issues/6573,1119082834,IC_kwDOAMm_X85Cs9lS,2448579,2022-05-05T21:57:58Z,2022-05-05T21:57:58Z,MEMBER,"Maybe we should add an explicit `join` kwarg, so the safe thing to specify is `join=""exact""`","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1226272301
https://github.com/pydata/xarray/issues/6573#issuecomment-1119076731,https://api.github.com/repos/pydata/xarray/issues/6573,1119076731,IC_kwDOAMm_X85Cs8F7,5635139,2022-05-05T21:47:59Z,2022-05-05T21:47:59Z,MEMBER,"It could be coherent to have:
- `v32.x.equals(v64.x)` be false — the indexes themselves aren't the same
- the join allow some float imprecision (similar to `method=nearest`), which would conveniently allow cases like this to work
I could also imagine raising an error here and having the user coerce the type. That seems less surprising that the current situation. Other languages don't allow floats to be compared for equality at all...","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1226272301
https://github.com/pydata/xarray/issues/6573#issuecomment-1119016401,https://api.github.com/repos/pydata/xarray/issues/6573,1119016401,IC_kwDOAMm_X85CstXR,4160723,2022-05-05T20:28:38Z,2022-05-05T20:31:04Z,MEMBER,"> The behaviour is likely caused by the fact that the indexes generated for the coordinates are no longer strictly equal, therefore where() picks only the two outer cells of each dimension.
Yes that's right:
```python
v32.indexes[""x""].intersection(v64.indexes[""x""])
# Float64Index([0.0, 1.0], dtype='float64', name='x')
```
I think the issue is more general than `where()` and relates to the alignment of Xarray objects with 32- vs 64-bit indexed coordinates:
```python
xr.align(c32, c64)
# (
# array([0. , 0.11111111, 0.22222222, 0.33333334, 0.44444445,
# 0.5555556 , 0.6666667 , 0.7777778 , 0.8888889 , 1. ],
# dtype=float32)
# Dimensions without coordinates: x,
#
# array([0. , 0.11111111, 0.22222222, 0.33333333, 0.44444444,
# 0.55555556, 0.66666667, 0.77777778, 0.88888889, 1. ])
# Dimensions without coordinates: x)
xr.align(v32.x, v64.x)
# (
# array([0., 1.], dtype=float32)
# Coordinates:
# * x (x) float64 0.0 1.0,
#
# array([0., 1.])
# Coordinates:
# * x (x) float64 0.0 1.0)
```
A possible solution would be to handle this special case internally by converting one of the index according to the dtype of the coordinate labels of the other index, similarly to what we are currently doing for the labels that are passed to `.sel()` (#3153). This should be pretty easy to implement in `PandasIndex.join()` I think.
However, I'm also wondering whether or not we should consider this as a bug. It would make sense to have a behavior that is consistent with `.sel()`, even though it is not a free nor transparent operation (implicit creation of a temporary pandas index). But how about `.equals()`? I.e.,
```python
v32.x.equals(v64.x)
# False -- Should we return True here?
```
This would be quite weird and wouldn't match the Xarray, Pandas and Numpy behavior below:
```python
v32.indexes[""x""].equals(v64.indexes[""x""])
# False
c64.equals(c32)
# False
np.all(c32.values == c64.values)
# False
```","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1226272301
https://github.com/pydata/xarray/issues/6573#issuecomment-1118239188,https://api.github.com/repos/pydata/xarray/issues/6573,1118239188,IC_kwDOAMm_X85CpvnU,5635139,2022-05-05T07:08:46Z,2022-05-05T07:08:46Z,MEMBER,"This does seem very odd. Does anyone have any ideas? As per @forman , changing
```diff
-c32 = xr.DataArray(np.linspace(0, 1, 10, dtype=np.float32), dims='x')
+c32 = xr.DataArray(np.linspace(0, 1, 10, dtype=np.float64), dims='x')
```
...causes the assertion to pass.
I'm not sure using floats as indexes is great, but I wouldn't have expected the results to be like this...
","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1226272301