-
Notifications
You must be signed in to change notification settings - Fork 192
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
Let var, std, cor take a CovarianceEstimator #734
Comments
Why not, but I guess you'd also expect CovarianceEstimation.jl (or another package) to define the corresponding functions? Otherwise it wouldn't be super useful. @mateuszbaran Any opinion? |
I’d propose including something like the default implementations above in StatsBase. At that point, so long as the first dispatch of |
Ah, got it. Yes, makes sense. Let's hear what @mateuszbaran says though. |
I think this definitely makes sense for |
To me, it seems nice to just implement a [I would be surprised if there aren't other regularisation techniques that would also fit this pattern - winsorising might be one off the top of my head] |
Sure, if you have a use for that, don't mind my comment 🙂 |
OK feel free to make a PR @tpgillam then. |
* Closes #734 * Undo drive-by tweak * Apparently needed to avoid duplicating docstrings * Bump version * Use private _cov2cor! for now
Currently
StatsBase.jl
definesCovarianceEstimator
here, and defines methods ofcov
that take one as the first argument.I think it would be convenient to allow similar dispatches for related methods. These could have fairly simple default implementations, something like the following (untested) sketch:
Any thoughts or objections to this? I'm happy to make a PR for more concrete discussion if this seems reasonable :)
The text was updated successfully, but these errors were encountered: