issue_comments

Table actions

5 rows where issue = 729980097 and user = 14314623 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

  • jbusecke · 5 ✖

issue 1

  • Option to skip tests in `weighted()` · 5 ✖

author_association 1

id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
717625573 https://github.com/pydata/xarray/issues/4541#issuecomment-717625573 https://api.github.com/repos/pydata/xarray/issues/4541 MDEyOklzc3VlQ29tbWVudDcxNzYyNTU3Mw== jbusecke 14314623 2020-10-28T00:45:31Z 2020-10-28T00:45:31Z CONTRIBUTOR

Another option would be to put the check in a .map_blocks call for dask arrays. This would only run and raise at compute time.

Uh that sounds great actually. Same functionality, no triggered computation, and no intervention needed from the user. Should I try to implement this?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Option to skip tests in `weighted()` 729980097
717266102 https://github.com/pydata/xarray/issues/4541#issuecomment-717266102 https://api.github.com/repos/pydata/xarray/issues/4541 MDEyOklzc3VlQ29tbWVudDcxNzI2NjEwMg== jbusecke 14314623 2020-10-27T14:03:34Z 2020-10-27T14:03:34Z CONTRIBUTOR

Thanks @mathause , I was wondering how much of a performance trade off .fillna(0) is on a dask array with no nans, compared to the check.

I favor this, since it allows slicing before the calculation is triggered: I have a current situation where I do a bunch of operations on a large multi-model dataset. The weights are time and member dependent and I am trying to save each member separately. Having the calculation triggered for the full dataset is problematic and fillna(0) avoids that (working with a hacked branch where I simply removed the check for nans)

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Option to skip tests in `weighted()` 729980097
716974071 https://github.com/pydata/xarray/issues/4541#issuecomment-716974071 https://api.github.com/repos/pydata/xarray/issues/4541 MDEyOklzc3VlQ29tbWVudDcxNjk3NDA3MQ== jbusecke 14314623 2020-10-27T04:33:04Z 2020-10-27T04:33:04Z CONTRIBUTOR

Sounds good. I'll see if I can make some time to test and put up a PR this week.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Option to skip tests in `weighted()` 729980097
716930400 https://github.com/pydata/xarray/issues/4541#issuecomment-716930400 https://api.github.com/repos/pydata/xarray/issues/4541 MDEyOklzc3VlQ29tbWVudDcxNjkzMDQwMA== jbusecke 14314623 2020-10-27T02:06:35Z 2020-10-27T02:06:35Z CONTRIBUTOR

What would happen in this case if a dask array with nans is passed? Would this somehow silently influence the results or would it not matter (in that case I wonder what the check was for). If this could lead to undetected errors I would still consider a kwargs a safer alternative, especially for new users?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Option to skip tests in `weighted()` 729980097
716927242 https://github.com/pydata/xarray/issues/4541#issuecomment-716927242 https://api.github.com/repos/pydata/xarray/issues/4541 MDEyOklzc3VlQ29tbWVudDcxNjkyNzI0Mg== jbusecke 14314623 2020-10-27T01:56:28Z 2020-10-27T01:56:28Z CONTRIBUTOR

Sorry if my initial issue was unclear. So you favor not having a 'skip' kwarg to just internally skipping the call to .any() if weights is a dask array?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Option to skip tests in `weighted()` 729980097

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]);