issue_comments
9 rows where issue = 977544678 sorted by updated_at descending
This data as json, CSV (advanced)
Suggested facets: reactions, created_at (date), updated_at (date)
issue 1
- Shoudn't `assert_allclose` transpose datasets? · 9 ✖
id | html_url | issue_url | node_id | user | created_at | updated_at ▲ | author_association | body | reactions | performed_via_github_app | issue |
---|---|---|---|---|---|---|---|---|---|---|---|
1128770505 | https://github.com/pydata/xarray/issues/5733#issuecomment-1128770505 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X85DR6vJ | mjwillson 4502 | 2022-05-17T11:48:26Z | 2022-05-17T11:48:26Z | NONE | +1 for a Or failing that, it would at least be nice to have As pointed out, most of the xarray API is dimension-order-invariant and so it's odd to have no supported way to do comparisons in a dimension-order-invariant way. |
{ "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
908436153 | https://github.com/pydata/xarray/issues/5733#issuecomment-908436153 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X842JaK5 | benbovy 4160723 | 2021-08-30T15:24:17Z | 2021-08-30T15:24:17Z | MEMBER | @jbusecke I agree with your point of view that "xarray-style" comparison is more practical in a scientific workflow. Especially if dimension order is irrelevant for most (all?) xarray operations, ignoring the order for However, it might be also dangerous / harmful if the workflow includes data conversion between labeled vs. unlabelled formats. There's a risk of checking for equality with xarray, then later converting to numpy and assuming that arrays are equal without feeling the need to check again. If dimension sizes are the same this might lead to very subtle bugs. Since it is easy to ignore or forget about default values, having a @dcherian I like your idea but I'm not sure what's best between your code snippet and checking equality of aligned dimensions datasets only if non-dimension-aligned are not equal. |
{ "total_count": 2, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 2, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
908433305 | https://github.com/pydata/xarray/issues/5733#issuecomment-908433305 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X842JZeZ | dcherian 2448579 | 2021-08-30T15:20:29Z | 2021-08-30T15:20:29Z | MEMBER |
I don't think we can change this because it's very backwards incompatible and affects tests in downstream packages. But :+1: to adding a flag allowing users to opt out of dimension order checking. |
{ "total_count": 2, "+1": 2, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
908406439 | https://github.com/pydata/xarray/issues/5733#issuecomment-908406439 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X842JS6n | TomNicholas 35968931 | 2021-08-30T14:48:23Z | 2021-08-30T14:48:23Z | MEMBER | I think we definitely need a flag, because we have two conflicting use cases:
1) Developers who use The easiest way to cover both is to have an option to switch between them. In my opinion the only question is what the default comparison behaviour should be. I like the idea of adding a |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
908389845 | https://github.com/pydata/xarray/issues/5733#issuecomment-908389845 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X842JO3V | jbusecke 14314623 | 2021-08-30T14:27:01Z | 2021-08-30T14:27:01Z | CONTRIBUTOR |
I guess this comes down a bit to a philosophical question related to @benbovy s comment above. You can either make this operation be similar to the numpy equivalent (with some more xarray specific checks) or it can check whether the values at a certain combo of labels are the same/close. The latter would be the way I think about data in xarray as a user. To me the removal of axis logic (via labels) is one of the biggest draws for myself, but importantly I also pitch this as one of the big reasons to switch to xarray for beginners. I would argue that a 'strict' (numpy style) comparision is less practical in a scientific workflow and we do have the numpy implementation to achieve that functionality. So I would ultimately argue that xarray should check closeness between values at certain label positions by default. However, this might be very opinionated on my end, and a better error message would already be a massive improvement. |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
907901984 | https://github.com/pydata/xarray/issues/5733#issuecomment-907901984 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X842HXwg | dcherian 2448579 | 2021-08-29T23:50:59Z | 2021-08-29T23:50:59Z | MEMBER | I have a related question ``` python import xarray as xr da = xr.DataArray([[1, 1, 1], [2, 2, 2]], dims=("x", "y")) xr.testing.assert_identical(da, da.transpose())
Strictly speaking, the values are different I guess. However I think this error would be clearer if it said that the dimension order was different but the values are equal once the dimensions are transposed. I.e. we could
Is this a good idea? |
{ "total_count": 2, "+1": 2, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
904683190 | https://github.com/pydata/xarray/issues/5733#issuecomment-904683190 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X8417F62 | dcherian 2448579 | 2021-08-24T14:16:45Z | 2021-08-24T14:16:45Z | MEMBER |
This sounds good to me. We should also have a |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
904552118 | https://github.com/pydata/xarray/issues/5733#issuecomment-904552118 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X8416l62 | benbovy 4160723 | 2021-08-24T11:21:22Z | 2021-08-24T11:21:22Z | MEMBER | Is there any operation in xarray where dimension order matters? If yes, I'm not sure if it's a good idea to allow transposed dimension pass
What about a |
{ "total_count": 1, "+1": 1, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 | |
904240540 | https://github.com/pydata/xarray/issues/5733#issuecomment-904240540 | https://api.github.com/repos/pydata/xarray/issues/5733 | IC_kwDOAMm_X8415Z2c | max-sixty 5635139 | 2021-08-24T01:09:19Z | 2021-08-24T01:09:19Z | MEMBER | I agree this is another station on the journey between "byte identical" and "practically similar", which we've discovered over the past couple of years... :) I would lean towards having it fail for |
{ "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
Shoudn't `assert_allclose` transpose datasets? 977544678 |
Advanced export
JSON shape: default, array, newline-delimited, object
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]);
user 6