[
https://issues.apache.org/jira/browse/NUMBERS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17440635#comment-17440635
]
Gilles Sadowski commented on NUMBERS-174:
-----------------------------------------
It looks like major improvements are underway. :)
{quote}Note that Commons Math 4 AccurateMath can compute these functions to 62
bit precision using a split double number. This is used internally for accurate
function rounding. However the API is not exposed and the exp and pow results
are limited to the 53-bit precision of a double.
{quote}
Could [Numbers] provide an equivalent to Boost's "long double" computations?
Could the
[{{Dfp}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/dfp/Dfp.java;h=02f7df81e38d533d893e96597a9dbbf2cf7f390c;hb=HEAD]
and [related
classes|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=tree;f=commons-math-legacy-core/src/main/java/org/apache/commons/math4/legacy/core/dfp;h=c548c79c6e29a966e147994f6ad1857d71340285;hb=HEAD]
be of use (and ported/refactored into [Numbers])?
Alternatively, should some of the computations use {{BigDecimal}} internally in
order to ensure accuracy equivalent to Boost's? Can this be done without "too
much" loss in performance (e.g. in the domains where inaccuracies would show up
in the {{double}} precision result)?
> Update Gamma functions using the Boost implementation
> -----------------------------------------------------
>
> Key: NUMBERS-174
> URL: https://issues.apache.org/jira/browse/NUMBERS-174
> Project: Commons Numbers
> Issue Type: Improvement
> Components: gamma
> Affects Versions: 1.0
> Reporter: Alex Herbert
> Assignee: Alex Herbert
> Priority: Major
> Fix For: 1.1
>
>
> The current regularised incomplete gamma functions for P and Q compute using
> a series representation for all input. This method is not robust to extreme
> arguments.
> The Gamma functions are used in Commons Statistics in the Gamma and Poisson
> distributions.
> Large values of the mean in the Poisson distribution have low
> precision for the CDF. The distribution also has a configurable
> threshold for convergence of the gamma function evaluation
> (STATISTICS-38). Ideally this implementation detail should be
> removed from the API.
> The Gamma distribution has a function switch based on a threshold to
> compute the PDF. This threshold results in incorrect values for
> certain parameters (STATISTICS-39).
> The function switch in the Gamma distribution is based on the
> documentation for the Boost gamma functions [1]. However it does not
> implement all the suggested optimisations detailed in the most recent
> Boost documentation. This includes avoiding using the converging
> series of the gamma function when the convergence is slow or unstable,
> i.e. addresses the need for a configurable convergence threshold in
> the Poisson distribution.
> One part of the evaluation of the incomplete gamma functions require
> accuracy in the leading term:
> {noformat}
> x^a exp(-x) / gamma(a) = exp(a log(x) - x - loggamma(a){noformat}
> When x and a are large then using logs to compute this leads to
> cancellation. Use of logs to compute this term is done in the current
> implementation in numbers for RegularizedGamma P and Q. It is the
> source of low precision for the CDF for the Poisson distribution when
> the mean is large.
> I propose to port the Boost gamma functions to numbers. This will be a
> process similar to the recent port of the error functions to the same
> package in numbers. These functions improved both accuracy and
> speed over the existing implementation. Once the gamma functions are
> ported a comparison can be made between the existing and new
> implementations.
> [1]
> [https://www.boost.org/doc/libs/1_77_0/libs/math/doc/html/math_toolkit/sf_gamma/igamma.html]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
