issue_comments

Table actions

2 rows where author_association = "MEMBER", issue = 1226272301 and user = 4160723 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: created_at (date), updated_at (date)

user 1

  • benbovy · 2 ✖

issue 1

  • 32- vs 64-bit coordinates coordinates in where() · 2 ✖

author_association 1

  • MEMBER · 2 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
1260551056 https://github.com/pydata/xarray/issues/6573#issuecomment-1260551056 https://api.github.com/repos/pydata/xarray/issues/6573 IC_kwDOAMm_X85LInuQ benbovy 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
}
   32- vs 64-bit coordinates coordinates in where() 1226272301
1119016401 https://github.com/pydata/xarray/issues/6573#issuecomment-1119016401 https://api.github.com/repos/pydata/xarray/issues/6573 IC_kwDOAMm_X85CstXR benbovy 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)

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

```

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   32- vs 64-bit coordinates coordinates in where() 1226272301

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);