You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The ddof kwarg has a different default to numpy. This means using the std() method on a Series or numpy.array with the same values give different results:
I assume the difference in behaviour is intentional, but I would suggest making this difference clearer in the documentation.
We could add the text: "Note that this normalization is different to numpy, which by default normalizes by N (equivalent to ddof=0)."
A similar string could be added in the kwarg description for ddof.
This would make it clear from reading the pandas docs that the behaviour is different to numpy, rather than having to compare the numpy docs side by side after noticing a discrepancy. It would also make users more likely to consider which ddof value they want for their use case.
If you agree, I am happy to make the PR to change this.
The text was updated successfully, but these errors were encountered:
Location of the documentation
https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.DataFrame.std.html
https://pandas.pydata.org/pandas-docs/dev/reference/api/pandas.Series.std.html
Documentation problem
The
ddof
kwarg has a different default to numpy. This means using thestd()
method on aSeries
ornumpy.array
with the same values give different results:Suggested fix for documentation
I assume the difference in behaviour is intentional, but I would suggest making this difference clearer in the documentation.
We could add the text: "Note that this normalization is different to numpy, which by default normalizes by N (equivalent to
ddof=0
)."A similar string could be added in the kwarg description for ddof.
This would make it clear from reading the pandas docs that the behaviour is different to numpy, rather than having to compare the numpy docs side by side after noticing a discrepancy. It would also make users more likely to consider which ddof value they want for their use case.
If you agree, I am happy to make the PR to change this.
The text was updated successfully, but these errors were encountered: