[
https://issues.apache.org/jira/browse/NUMBERS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17706923#comment-17706923
]
Alex Herbert commented on NUMBERS-167:
--------------------------------------
The update gamma implementation is far more complex than the previous version
based on a continued fraction computation. That method could benefit from
precomputation of a LogGamma value. The new implementation uses more than
LogGamma depending on the domain of the argument (it may use Gamma or
LogGamma). When I looked at precomputing some factors I did not see a simple
implementation and left it.
Feel free to have a look at the function internals. It may be possible to save
some computation. A JMH test should be used to determine if this is more than
just a marginal difference. IIRC I decided it was non-trivial.
> 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.2
>
> 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.20.10#820010)
