issue_comments

Table actions

5 rows where author_association = "MEMBER" and issue = 470024896 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

issue 1

  • Implementing map_blocks and map_overlap · 5 ✖

author_association 1

  • MEMBER · 5 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
668256401 https://github.com/pydata/xarray/issues/3147#issuecomment-668256401 https://api.github.com/repos/pydata/xarray/issues/3147 MDEyOklzc3VlQ29tbWVudDY2ODI1NjQwMQ== TomAugspurger 1312546 2020-08-03T21:42:42Z 2020-08-03T21:42:42Z MEMBER

Thanks for that link. I hope that map_overlap could use pad internally for the external boundaries.

On Mon, Aug 3, 2020 at 3:22 PM Deepak Cherian notifications@github.com wrote:

This issue about coordinate labels for boundaries exists with pad too:

3868 https://github.com/pydata/xarray/issues/3868

Can map_overlap just use DataArray.pad and we can fix things there?

Or perhaps we can expect users to add a call to pad before map_overlap?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pydata/xarray/issues/3147#issuecomment-668223125, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKAOIWLGJZYO63S7IXTEH3R64MAZANCNFSM4IFAIWOA . 

{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Implementing map_blocks and map_overlap 470024896
668223125 https://github.com/pydata/xarray/issues/3147#issuecomment-668223125 https://api.github.com/repos/pydata/xarray/issues/3147 MDEyOklzc3VlQ29tbWVudDY2ODIyMzEyNQ== dcherian 2448579 2020-08-03T20:22:23Z 2020-08-03T20:22:23Z MEMBER

This issue about coordinate labels for boundaries exists with pad too: https://github.com/pydata/xarray/issues/3868

Can map_overlap just use DataArray.pad and we can fix things there?

Or perhaps we can expect users to add a call to pad before map_overlap?

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Implementing map_blocks and map_overlap 470024896
668209121 https://github.com/pydata/xarray/issues/3147#issuecomment-668209121 https://api.github.com/repos/pydata/xarray/issues/3147 MDEyOklzc3VlQ29tbWVudDY2ODIwOTEyMQ== TomAugspurger 1312546 2020-08-03T19:47:47Z 2020-08-03T19:47:57Z MEMBER

I'm thinking through a map_overlap API right now. In dask, map_overlap requires a few extra arguments

depth: int, tuple, dict or list The number of elements that each block should share with its neighbors If a tuple or dict then this can be different per axis. If a list then each element of that list must be an int, tuple or dict defining depth for the corresponding array in `args`. Asymmetric depths may be specified using a dict value of (-/+) tuples. Note that asymmetric depths are currently only supported when ``boundary`` is 'none'. The default value is 0. boundary: str, tuple, dict or list How to handle the boundaries. Values include 'reflect', 'periodic', 'nearest', 'none', or any constant value like 0 or np.nan. If a list then each element must be a str, tuple or dict defining the boundary for the corresponding array in `args`. The default value is 'reflect'.

In dask.array those must be dicts whose keys are the axis number. For xarray we would want to allow the dimension names there.

I'm not sure how to handle the DataArray labels for the boundary chunks (dask docs at https://docs.dask.org/en/latest/array-overlap.html#boundaries). For reflect / periodic I think things are OK, we perhaps just use the label associated with that value. I'm not sure what to do for constants.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Implementing map_blocks and map_overlap 470024896
540845903 https://github.com/pydata/xarray/issues/3147#issuecomment-540845903 https://api.github.com/repos/pydata/xarray/issues/3147 MDEyOklzc3VlQ29tbWVudDU0MDg0NTkwMw== jhamman 2443309 2019-10-11T00:00:59Z 2019-10-11T00:00:59Z MEMBER

map_blocks went in as of #3276. We'll leave this open for the future work implementing map_overlap.

 
{
    "total_count": 4,
    "+1": 3,
    "-1": 0,
    "laugh": 0,
    "hooray": 1,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Implementing map_blocks and map_overlap 470024896
513021156 https://github.com/pydata/xarray/issues/3147#issuecomment-513021156 https://api.github.com/repos/pydata/xarray/issues/3147 MDEyOklzc3VlQ29tbWVudDUxMzAyMTE1Ng== dcherian 2448579 2019-07-18T22:50:40Z 2019-07-18T22:50:40Z MEMBER

+1. The split_by_chunks method in this comment (https://github.com/pydata/xarray/issues/1093#issuecomment-259213382) would also be useful for more general per-chunk manipulation.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Implementing map_blocks and map_overlap 470024896

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