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.

the join allow some float imprecision (similar to method=nearest), which would conveniently allow cases like this to work

I like that.

Maybe we should add an explicit join kwarg, so the safe thing to specify is join="exact"

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...

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)

(<xarray.DataArray (x: 10)>

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,

<xarray.DataArray (x: 10)>

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)

(<xarray.DataArray 'x' (x: 2)>

array([0., 1.], dtype=float32)

Coordinates:

* x (x) float64 0.0 1.0,

<xarray.DataArray 'x' (x: 2)>

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

```

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...