-
Notifications
You must be signed in to change notification settings - Fork 421
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
Use Julia implementations of normpdf
etc. in StatsFuns
#1487
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a good idea in general. Although it looks like StatsBase's normal quantile function promotes to Float64
unnecessarily (see failures).
Should we bump the Julia bound to 1.3 or 1.6? The test errors on Julia 1.0 are caused by an ancient version of SpecialFunctios (0.8 😮) that does not contain implementations of |
Alternatively, we could just not run these failing tests on Julia < 1.3. |
Codecov Report
@@ Coverage Diff @@
## master #1487 +/- ##
==========================================
+ Coverage 84.80% 84.92% +0.12%
==========================================
Files 126 128 +2
Lines 7778 7735 -43
==========================================
- Hits 6596 6569 -27
+ Misses 1182 1166 -16
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thanks for merging the PR @mschauer! I guess Distributions doesn't follow the ColPrac guidelines officially but maybe we should adopt the policy that PR authors with merge rights merge their own PRs. Even after a PR is approved I sometimes notice an issue that has to be addressed or something minor that I'd like to change (wasn't the case here 🙂), and then it's nice if the PR is not merged yet and I can update it. |
Is it intentional that this PR removed |
Yes. |
But are they still exported and defined for many other distributions? |
They are just internal helpers that simplify the code a bit and make it more readable. BTW StatsFuns uses internal helpers of the same name: https://github.com/JuliaStats/StatsFuns.jl/blob/13e231a0a22e716426b73cb87ff3b8b24e33aaf1/src/distrs/norm.jl#L3 |
The polymorphic nature of the Distribution.jl ones is/was quite convenient. |
I don't understand, why would you you want them to be imported? They are not exported by StatsFuns because they are an internal implementation detail. So if you want to use them you could just call |
I don't want As for the ones in StatsFuns.jl, since they are not exported, the name clash with Distributions.jl is not critical, but to be consistent with the other normal-related functions there, they could be renamed into normzval/normxval(). |
Taking one step back, what exactly do you expect that |
That's what I expect (for the transformed distribution the mean is zero, the std is one), and that's why I specify that it might make sense to define it only for symmetric continuous univariate. |
In that case, can't you define and use this function |
I can, I was just wondering if it could be implemented by the package, given that |
This PR replaces the implementations of
pdf(::Normal, ::Real)
etc. with calls toStatsFuns.normpdf
etc. which are basically the same Julia implementations.This removes code duplication (which e.g. means that one would not have to define ChainRules derivatives in both packages but it is sufficient to do so in StatsFuns) and it actually fixes subtle bugs such as reported in #1067 (comment) and arising from undesired promotions in
Normal(mu, sigma)
calls in the current implementation in Distributions.Tests require JuliaStats/StatsFuns.jl#132 which fixes a bug in the StatsFuns implementation covered by our tests.