Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Tue, 1 May 2012 02:54:49 +0000 (UTC)
From: "Colin J. Fuller (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <387434206.12272.1335840889789.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (MATH-785) Numerical Underflow in
 ContinuedFraction
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Colin J. Fuller created MATH-785:
------------------------------------

             Summary: Numerical Underflow in ContinuedFraction
                 Key: MATH-785
                 URL: https://issues.apache.org/jira/browse/MATH-785
             Project: Commons Math
          Issue Type: Bug
    Affects Versions: 3.0
         Environment: Issue seen in both 3.0 release binary version as well=
 as a fresh checkout of the subversion trunk.

java -version output:

java version "1.6.0_26"
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

(On Ubuntu 12.04)


            Reporter: Colin J. Fuller


The ContinuedFraction calculation can underflow in the evaluate method, sim=
ilar to the overflow case already dealt with.  I encountered this problem w=
hile trying to evaluate the inverse cumulative probability of an F distribu=
tion with a large number of degrees of freedom.

I would guess this has the same cause as MATH-718 and MATH-738, though I am=
 not experiencing inaccurate results but rather an exception.

For instance, the following test case fails:

double prob =3D 0.01;
FDistribution f =3D new FDistribution(200000, 200000);
double fails =3D f.inverseCumulativeProbability(prob);

This produces a NoBracketingException with the following stack trace:

org.apache.commons.math3.exception.NoBracketingException: function values a=
t endpoints do not have different signs, endpoints: [0, 1], values: [-0.01,=
 -=E2=88=9E]
=09at org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSo=
lver.java:118)
=09at org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolve=
r.solve(BaseAbstractUnivariateSolver.java:190)
=09at org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolve=
r.solve(BaseAbstractUnivariateSolver.java:195)
=09at org.apache.commons.math3.analysis.solvers.UnivariateSolverUtils.solve=
(UnivariateSolverUtils.java:77)
=09at org.apache.commons.math3.distribution.AbstractRealDistribution.invers=
eCumulativeProbability(AbstractRealDistribution.java:156)

I could avoid the issue as in the comment to MATH-718 by relaxing the defau=
lt value of epsilon in ContinuedFraction, although in my test case I can't =
see any reason the current default precision shouldn't be attainable.

I fixed the issue by implementing underflow detection in ContinuedFraction =
and rescaling to larger values similarly to how the overflow detection that=
 is already there works.  I will attach a patch shortly.

One possible issue with this fix is that if there exists a case where there=
 is a legitimate reason for p2 or q2 to be zero (I cannot think of one), it=
 might break that case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira