Skip to content
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

Moving forward with standard deviation and standard error function names. #369

Closed
Nosferican opened this issue Apr 8, 2018 · 6 comments
Closed

Comments

@Nosferican
Copy link
Contributor

Currently StatsBase has std for standard deviation and used stderr for standard error. Given the decision at Base to use stderr as one of the three input/output (I/O) connections, StatsBase must decide how to rename it.

Possible candidates include:

  • sd and se
  • stddev and stderror

Relevant discussions occurred in julia PR#26636, Slack #statistics, and #368.

@ararslan
Copy link
Member

ararslan commented Apr 8, 2018

+1 for stddev and stderror. I think we should favor more descriptive names wherever possible. Also note that there's likely a lot of code that currently uses sd and se as variable names, which would then be broken by claiming those names for the functions themselves.

@Nosferican
Copy link
Contributor Author

Those are two very valid arguments.

stderror(model)

would still be a bit shorter than

sqrt.(diag(vcov(model)))

which is at least the longest the standard error function should be.

@nalimilan
Copy link
Member

Why not, but if we rename std to stddev, we should do the same in Base.

@stevengj
Copy link
Contributor

stevengj commented Apr 9, 2018

My suggestion would be to leave std as-is, and use stderror for the standard error.

The standard deviation is more common, std is a well known name for it that hasn't caused any problems so far, and std mirrors var. Also, leaving std (and var) as-is would be less disruptive.

@ararslan
Copy link
Member

ararslan commented Apr 9, 2018

Sure, that makes sense to me.

@nilshg
Copy link

nilshg commented Mar 28, 2023

This is probably decided now so can be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants