[
https://issues.apache.org/jira/browse/NUMBERS-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17707651#comment-17707651
]
Alex Herbert commented on NUMBERS-167:
--------------------------------------
{quote}Doesn't it entail that it is quite likely that is much slower and
potentially less accurate than what is implemented in that other library?
{quote}
It was not clear which is slower. Anyway, the inverse CDF/SF are a place where
improvements can be made.
The default implementation in Statistics remains the bracketed search using a
BrentOptimizer. This had to have updates to improve the version from CM to
tighten the tolerances in the BrentOptimizer and support inversion of
sub-normal numbers. It may not be very fast, and it often has lower relative
accuracy than other implementations used to test the function (e.g. in SciPy,
Matlab, R). The inverse functions are the main place where the relative
tolerance used in the test suite has to be lowered.
The most obvious improvement is to use a derivative based inversion method to
guide the search. This is what is performed in the Boost inversion of the
incomplete Gamma function used for the Gamma distribution (and derived
Chi-squared distribution). However I have not tested the Boost function to
check if the method is faster and/or more accurate than what we have.
{quote}There seems to be an issue with the generated API docs ... for code of
the package-private AbstractContinuousDistribution
{quote}
Yes. I just checked. Any non-public classes do not have generated source pages.
If you run:
{noformat}
mvn javadoc:javadoc -Dshow=package{noformat}
Then the src link does not error as the source HTML is generated for the
package-private class. However the class also appears in the main Javadoc pages
too. I cannot find an option to generate the src pages (desirable) without also
adding the same classes to the Javadoc pages (which is less desirable).
See
[https://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#show]
> 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)
