Commons Math
  1. Commons Math
  2. MATH-785

Numerical Underflow in ContinuedFraction

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.0
    • Fix Version/s: 3.1
    • Labels:
      None
    • Environment:

      Description

      The ContinuedFraction calculation can underflow in the evaluate method, similar to the overflow case already dealt with. I encountered this problem while trying to evaluate the inverse cumulative probability of an F distribution 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 = 0.01;
      FDistribution f = new FDistribution(200000, 200000);
      double fails = f.inverseCumulativeProbability(prob);

      This produces a NoBracketingException with the following stack trace:

      org.apache.commons.math3.exception.NoBracketingException: function values at endpoints do not have different signs, endpoints: [0, 1], values: [-0.01, -∞]
      at org.apache.commons.math3.analysis.solvers.BrentSolver.doSolve(BrentSolver.java:118)
      at org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:190)
      at org.apache.commons.math3.analysis.solvers.BaseAbstractUnivariateSolver.solve(BaseAbstractUnivariateSolver.java:195)
      at org.apache.commons.math3.analysis.solvers.UnivariateSolverUtils.solve(UnivariateSolverUtils.java:77)
      at org.apache.commons.math3.distribution.AbstractRealDistribution.inverseCumulativeProbability(AbstractRealDistribution.java:156)

      I could avoid the issue as in the comment to MATH-718 by relaxing the default 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.

      1. patch.txt
        2 kB
        Colin J. Fuller

        Issue Links

          Activity

          No work has yet been logged on this issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              Colin J. Fuller
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development