Skip to content

BUG: rolling with Int64 #43174

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 5 commits into from
Aug 31, 2021
Merged

BUG: rolling with Int64 #43174

merged 5 commits into from
Aug 31, 2021

Conversation

mroeschke
Copy link
Member

@mroeschke mroeschke added the Window rolling, ewma, expanding label Aug 23, 2021
@mroeschke mroeschke added this to the 1.4 milestone Aug 23, 2021
phofl
phofl approved these changes Aug 23, 2021
View reviewed changes
Copy link
Member

@phofl phofl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm excluding mypy error

jreback
jreback reviewed Aug 23, 2021
View reviewed changes
pandas/core/window/rolling.py Outdated
@@ -318,7 +318,11 @@ def _prep_values(self, values: ArrayLike) -> np.ndarray:
# GH #12373 : rolling functions error on float32 data
# make sure the data is coerced to float64
try:
values = ensure_float64(values)
if hasattr(values, "to_numpy"):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should change ensure_float64 to just do this directly (eg put your change there) - need to check perf and that this doesn't break anything

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can do isinstance instead of hasattr?

jreback
jreback requested changes Aug 26, 2021
View reviewed changes
pandas/tests/window/test_dtypes.py
# GH 43016
s = Series([0, 1, NA], dtype=any_signed_int_ea_dtype)
result = s.rolling(2).mean()
expected = Series([np.nan, 0.5, np.nan])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't we actually replace and use pd.NA as the output? or is this too big of a change?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, but currently all rolling/expanding/ewm results always return np.float64 (which is documented as well). So that would be a big change to return the same dtype as the caller.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, do we have an issue about this? we should make this change in 1.4

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#11446

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm no was speaking about supporting pd.NA specifically (i think rolling_apply is totally fine) if you can add one

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I modified that issue to generally support same input/output dtypes (which include ExtensionDtypes that support pd.NA)

@jreback jreback added the NA - MaskedArrays Related to pd.NA and nullable extension arrays label Aug 26, 2021
jbrockmendel
jbrockmendel reviewed Aug 27, 2021
View reviewed changes
pandas/_libs/algos_common_helper.pxi.in Outdated
@@ -66,6 +66,10 @@ def ensure_{{name}}(object arr, copy=True):
return arr
else:
return arr.astype(np.{{dtype}}, copy=copy)
{{if na_val == "nan"}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

im really not sure about this. ensure_foo is fast ATM, plus this introduces circular dependency

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think ensure_foo should not be used directly on ExtentionArrays i.e. ensure_foo(arr.to_numpy(...))?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess. mainly i think that pd.NA is way more trouble than its worth

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm i did request this, but agree the performance tradeoff might not be worthit.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think maybe making an ensure_*_with_na is prob better here (and make it the caller responsible if we have an EA)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I went with @jbrockmendel's original isinstance check instead for now. For the ensure_foo_with_na feature, probably should be another issue to discuss because it would be potentially useful anywhere ensure_foo is called.

jreback
jreback requested changes Aug 30, 2021
View reviewed changes
pandas/tests/window/test_dtypes.py
# GH 43016
s = Series([0, 1, NA], dtype=any_signed_int_ea_dtype)
result = s.rolling(2).mean()
expected = Series([np.nan, 0.5, np.nan])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, do we have an issue about this? we should make this change in 1.4

pandas/_libs/algos_common_helper.pxi.in Outdated
@@ -66,6 +66,10 @@ def ensure_{{name}}(object arr, copy=True):
return arr
else:
return arr.astype(np.{{dtype}}, copy=copy)
{{if na_val == "nan"}}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm i did request this, but agree the performance tradeoff might not be worthit.

@jreback jreback merged commit 344c691 into pandas-dev:master Aug 31, 2021
@jreback
Copy link
Contributor

jreback commented Aug 31, 2021

thanks @mroeschke

@jbrockmendel
Copy link
Member

jbrockmendel commented Aug 31, 2021 •
edited
Loading

FWIW:

In [1]: import numpy as np

In [2]: import pandas as pd

In [3]: from pandas.core.dtypes.common import *

In [4]: arr = np.arange(5, dtype=np.int64)

In [5]: %timeit np.asarray(arr, dtype=np.int64)
150 ns ± 14 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [6]: %timeit arr.astype(np.int64, copy=False)
181 ns ± 13.3 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

In [7]: %timeit ensure_int64(arr)
63.1 ns ± 8.89 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)

The absolute cost is very small, but its optimized to the bone.

@mroeschke mroeschke deleted the bug/series_null_int_rolling branch September 1, 2021 04:48
@janlugt
Copy link

janlugt commented Sep 6, 2021

I think this also fixed my issue in #43381. Any chance it can be backported to the 1.3.x branch?

@phofl
Copy link
Member

phofl commented Sep 6, 2021

We backport only regression fixes

feefladder pushed a commit to feefladder/pandas that referenced this pull request Sep 7, 2021
@mroeschke @feefladder
BUG: rolling with Int64 (pandas-dev#43174)
5c024e2
@mroeschke mroeschke mentioned this pull request Nov 2, 2021
Closed
3 tasks
@simonjayhawkins simonjayhawkins mentioned this pull request Nov 10, 2021
Closed
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jbrockmendel jbrockmendel jbrockmendel left review comments

@jreback jreback jreback approved these changes

@phofl phofl phofl approved these changes

Assignees
No one assigned
Labels
NA - MaskedArrays Related to pd.NA and nullable extension arrays Window rolling, ewma, expanding
Projects
None yet
Milestone
1.4
Development

Successfully merging this pull request may close these issues.

BUG: rolling fails when Series contains pd.NA
5 participants
@mroeschke @jreback @jbrockmendel @janlugt @phofl