Use erfinv for cdf of Normal? about distributions.jl HOT 15 CLOSED

I meant using erfinv for the quantile function and erf for the cdf, of course.

from distributions.jl.

One quick check of their disagreement gives this:

julia> using Distributions

julia> phi(x) = 0.5 + 0.5 * erf(x / sqrt(2))
# methods for generic function phi
phi(x) at none:1

julia> max(map(x -> abs(cdf(Normal(), x) - phi(x)), -5.0:0.1:5.0))
1.1102230246251565e-16

from distributions.jl.

This seems like it's on the order of round-off error, but it would be good to hear from others before making the change.

from distributions.jl.

And here's the other direction:

julia> invphi(p) = sqrt(2) * erfinv(2 * p - 1.0)
# methods for generic function invphi
invphi(p) at none:1

julia> max(map(p -> abs(quantile(Normal(), p) - invphi(p)), 0.0:0.01:1.0))
5.329070518200751e-15

from distributions.jl.

One advantage of using erf is that it is defined for the BigFloat type. I haven't checked to see whether this should provide more accuracy than the converting the Float64 result to BigFloat.

from distributions.jl.

The BigFloat point is definitely worth keeping in mind.

Do you have a sense of how we should go about deciding whether the function definition I proposed is (1) sufficiently accurate and (2) sufficiently fast?

from distributions.jl.

For the cdf we could use the BigFloat evaluation and compare the results of the Rmath call and the erf-based Float64 version. I assume that the authors of the GNU MPFR library can be counted upon to get the "correct" Float64 value after converting their BigFloat result.

As for sufficiently fast we could time the two methods but both are going to be so fast that it will be difficult to disitnguish.

from distributions.jl.

In commit 6008e71 on the db/Normal branch I wrote just the pdf and logpdf in Julia simply to test them out. One thing that can be done in pure Julia code is to create templated types allowing for BigFloat distributions, should anyone want them. For this purpose I added math_const values of some values like log2pi.

I also switched the names of the fields in the type to the unicode characters for mu and sigma. What do others think? Is this too cute or would it ultimately be helpful for those trying to related parameters to a text-book representation?

from distributions.jl.

I really like the unicode characters, but am hesitant to use them when the end-user might need to access the variables. So I'm not sure we should use unicode for the fields of Distributions, even though it does look really nice.

from distributions.jl.

There's always cut-and-paste :-)

from distributions.jl.

Also, in this case mean(d) and std(d) provide easy extractors.

from distributions.jl.

That's very true. I'm happy with requiring people to use mean(d) and std(d) since I'd like our implementation details not to bleed into the end-user API.

For me, the main reason that the Greek characters are so usable is that I can set my OS X keyboard to map to Greek, which puts the characters were I expect them: p is pi, s is sigma, etc.

from distributions.jl.

So was the decision to allow Greek characters for the parameters of a distribution as long as there are convenient extractor functions that can be typed on a conventional keyboard?

from distributions.jl.

I think the decision was that we'll only use Greek letters as local variables, but I'm not totally sure.

from distributions.jl.

Closed via 4cdc884

from distributions.jl.