issues

Table actions

2 rows where repo = 13221727, state = "open" and user = 5802846 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

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

type 2

state 1

  • open · 2 ✖

repo 1

  • xarray · 2 ✖
id node_id number title user state locked assignee milestone comments created_at updated_at ▲ closed_at author_association active_lock_reason draft pull_request body reactions performed_via_github_app state_reason repo type
535686852 MDExOlB1bGxSZXF1ZXN0MzUxMzU0OTI4 3607 Strided rolling niowniow 5802846 open 0     3 2019-12-10T12:05:54Z 2023-03-09T20:37:56Z   CONTRIBUTOR   0 pydata/xarray/pulls/3607

This PR adds a stride parameter to the rolling function of DataArray and Dataset . It basically extends the stride functionality being available for core.rolling.DataArrayRolling.construct and core.rolling.DatasetRolling.construct to the other methods of DataArrayRolling and DatasetRolling.

Note: it makes the arguments of DataArrayRolling and DatasetRolling inconsistent with the respective rolling arguments of pandas Series and DataFrame (They do not support stride). Moreover, it does not solve the issue addressed in this pandas issue (Efficient stride computation).

  • [x] Tests added
  • [x] Passes black . && mypy . && flake8
  • [x] Fully documented, including whats-new.rst for all changes and api.rst for new API
 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3607/reactions",
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 pull
535703663 MDU6SXNzdWU1MzU3MDM2NjM= 3608 Feature Request: Efficient rolling with strides niowniow 5802846 open 0     8 2019-12-10T12:38:59Z 2021-07-28T11:58:28Z   CONTRIBUTOR      

Xarray is facing the same issues in its current rolling implementation (DataArrayRolling and DatasetRolling) as described in this pandas issue. Namely, the construct methods stride parameter is applied after the rolling is computed. Technically, we are computing more than we would need to because we partially throwing it away due to striding.

In PR #3607 the issue is solved for the ...Rolling's __iter__ function but not for the construct, reduce and _bottleneck_reduce methods. Since the way Xarray's rolling is implemented relies on numpy, we could introduce a sliding window function as described here.

Any opinions?

 
{
    "url": "https://api.github.com/repos/pydata/xarray/issues/3608/reactions",
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
     xarray 13221727 issue

Advanced export

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

CSV options: 

CREATE TABLE [issues] (
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [number] INTEGER,
   [title] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [state] TEXT,
   [locked] INTEGER,
   [assignee] INTEGER REFERENCES [users]([id]),
   [milestone] INTEGER REFERENCES [milestones]([id]),
   [comments] INTEGER,
   [created_at] TEXT,
   [updated_at] TEXT,
   [closed_at] TEXT,
   [author_association] TEXT,
   [active_lock_reason] TEXT,
   [draft] INTEGER,
   [pull_request] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [state_reason] TEXT,
   [repo] INTEGER REFERENCES [repos]([id]),
   [type] TEXT
);
CREATE INDEX [idx_issues_repo]
    ON [issues] ([repo]);
CREATE INDEX [idx_issues_milestone]
    ON [issues] ([milestone]);
CREATE INDEX [idx_issues_assignee]
    ON [issues] ([assignee]);
CREATE INDEX [idx_issues_user]
    ON [issues] ([user]);