[
https://issues.apache.org/jira/browse/NUMBERS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427366#comment-17427366
]
Alex Herbert commented on NUMBERS-167:
--------------------------------------
Sorry for the delay in replying. I have been looking at the gamma function in
the Boost implementation as this is the basis of the function choice for the
GammaDistribution PDF which has an issue for small x (see STATISTICS-39). The
current implementation in numbers for P and Q uses a continued fraction. This
is switched when x > a+1. The reason for the switch is the result of P or Q is
around 0.5 when a ~ x.
The Boost implementation has 1 function to evaluate the gamma and regularized
gamma functions (4 functions in total). It is called with different arguments
to indicate whether to invert and to normalise. It can compute the derivative
of P which covers the GammaDistribution PDF and handles values of P or Q close
to 0.5 with a different method as the continued fractions are slow to converge.
In common use the switch from P to Q is made when x - 1/3x > a. This avoids the
result of P or Q being > 0.75. There is additional handling for x < 1.1 which
is where the issue is in the GammaDistribution.
The end result being that it may be better to hold off creating an API
extension for constant a or x arguments. I would rather update the current
Gamma functions to use the additions made in the Boost implementation to
improve accuracy at values poorly supported by the continued fraction
implementation.
See Also:
[Boost Gamma
distribution|https://www.boost.org/doc/libs/1_77_0/libs/math/doc/html/math_toolkit/dist_ref/dists/gamma_dist.html]
[Boost gamma
functions|https://www.boost.org/doc/libs/1_77_0/libs/math/doc/html/math_toolkit/sf_gamma/igamma.html]
> RegularizedGamma.P with precomputed LogGamma value
> --------------------------------------------------
>
> Key: NUMBERS-167
> URL: https://issues.apache.org/jira/browse/NUMBERS-167
> Project: Commons Numbers
> Issue Type: Wish
> Components: gamma
> Reporter: Gilles Sadowski
> Priority: Minor
> Fix For: 1.1
>
> Attachments: pr_106.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We have
> {code:java}
> double v = RegularizedGamma.P.value(a, x);
> {code}
> where method {{value}} internally calls {{LogGamma.value(a)}}.
> There is a use-case for
> {code:java}
> double logGammaA = LogGamma.value(a);
> double v = RegularizedGamma.P.value(a, x, logGammaA);
> {code}
> for when the user varies {{x}} but not {{a}}.
> Method name TBD: Another overload of {{value}} may be confusing (?).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
