-
-
Notifications
You must be signed in to change notification settings - Fork 5.1k
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
consistency of std interface (Trac #1200) #1727
Comments
@bsouthey wrote on 2010-06-16 Just a few explanations. I created two new functions, one for the variance and one for the standard deviation (since it the square root of the variance). The dtype argument is for the internal calculations and is only relevant when the dtype argument is float128. Numpy automatically converts the input to float64 so dtype is only used when for dtypes with higher precision (currently float128). HoweverSo I cheated by only converting the input to float128 when the dtype was float128. I do not know how to implement the out argument although it can be achieved by converting the input to a masked array. I also added a check for masked arrays so that if the input is a masked array so that the appropriate masked array function is used. |
@rgommers wrote on 2010-11-21 First on the signatures (of nanstd, but other nan functions as well): this can not be done in a backwards-compatible way, which is a pain. Both On Bruce's patch: a nanvar function would be a good addition. But the nan* funcs do not handle masked arrays, neither should this one I think. That's what mstats is for. Furthermore the axis handling works only for 2-D it seems, look at other nan* funcs to see how it's done there (specifically |
Attachment added by @rgommers on 2010-11-21: stats_biaskw.patch |
@rgommers wrote on 2011-08-19 Do we want to apply this patch for 0.10? |
@rgommers wrote on 2011-09-11 Tried to make this change, it's not pretty. I don't want to do this for 0.10, and preferably not at all. We should have a nanstd in numpy relatively soon. |
I don't think it's worth anymore to worry about this We can deprecate and remove them from scipy.stats when the required numpy version is large enough. Do we need an open issue for a deprecation (or FutureWarning) cycle and for delegating to numpy.nan in the meantime, if the numpy versions are available? added milestone 0.14 |
Should be OK to deprecate for 0.14.0. No hurry to do it now. |
Or 0.15.0 - didn't get around to this in time. |
Original ticket http://projects.scipy.org/scipy/ticket/1200 on 2010-06-16 by trac user amcmorl, assigned to unknown.
scipy.stats.nanstd and numpy.std have different signatures, which should be made consistent:
scipy.stats.nanstd(x, axis=0, bias=False)
vs
numpy.std(a, axis=None, dtype=None, out=None, ddof=0)
Most important is changing the bias keyword to ddof.
The dtype parameter may not be relevant to nanstd since nans only exist in floats (what about complex?).
The text was updated successfully, but these errors were encountered: