-
-
Notifications
You must be signed in to change notification settings - Fork 18.4k
API: meaning of min_periods for ewm*() functions? #7977
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.
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
Comments
Anyone have an opinion on this? Specifically, I would replace
with
I suppose another alternative is simply:
It just seems odd to me that input Given that the |
@seth-p I think this is right, can you give an example using (your second alternative to set nans)? |
Here are some examples of data frames showing:
The following is the code that produced the tables above.
|
Anyone have any thoughts? As I mentioned above, I favor "Alt 1", for consistency with the |
I agree on Alt 1 (Alt 2 is a bit greedy). |
OK, I will incorporate this into #7926. |
maybe add something like the above chart into the release notes (but only show the 0.14.1 and the new) |
Good idea. |
also could be a note in computation.rst (as sort of an edge case example) |
The interpretation of
min_periods
in theewm*()
functions seems rather odd to me. For example (in 0.14.1):The way it works, is it finds the first non-
NaN
value (0
in the example above) and then makes sure that themin_periods
entries (min_periods-1
in 0.15.0, per #7898) in the result starting at that entry areNaN
. Does it make any sense that the result has entry0
set toNaN
, but entries2
and3
(and1
in 0.15.0) set to0.0
?I would have thought that the values to be explicitly
NaN
ed would be those determined byx.notnull().cumsum() < min_periods
. This would be consistent with the meaning ofmin_periods
in therolling_*()
andexpanding_*()
functions.CC'ing @snth and @jaimefrio, in case they have opinions.
The text was updated successfully, but these errors were encountered: