commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luc Maisonobe (JIRA)" <>
Subject [jira] Commented: (MATH-433) Signal overflow by raising an exception
Date Sun, 07 Nov 2010 10:52:09 GMT


Luc Maisonobe commented on MATH-433:

I don't think so, but you are right to point this out, as we are inconsistent in the library
about it, so this point has to be decided upon.
The reason I don't think it would be wise is that IEEE754 rules have been very cleverly defined.
They are very good one and we should stick with them as much as possible. Also (and it is
a major point IMHO), special values are not always problems. There are many cases where infinity
are a valid output and not an error. There are far fewer cases where NaNs are valid output
(I don't know any in fact) but there are cases where NaNs are valid input values, mainly used
to identify not initialized, free, unknown or unused parameters. They are used to switch from
one branch algorithm to another one.
A quick search in commons-math showed that we use NaNs in more than 200 locations (more than
500 locations if we consider tests).
In global algorithms like root solvers, ODE solvers or optimizers, we often don't handle these
values properly. Hopefully, some times we do so: I found 125 calls to Double.isNaN in the
library itself. Many of these uses are precisely to switch from a special value resulting
from some computation to an error. An example is in the inverseCumulativeProbability in the
AbstractContinuousDistribution class: we test for a function value and if it is a NaN, we
throw a FunctionEvaluationException (this code appears in an internal implementation of the
UnivariateRealFunction interface).

> Signal overflow by raising an exception
> ---------------------------------------
>                 Key: MATH-433
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>            Reporter: Gilles
>            Priority: Minor
> Referring to the ML thread (with subject "Factorial").
> Shouldn't Commons-Math always raise an exception when overflow is detected, including
in cases where the Java language specification has decided to return infinity?
> It was argued, in the ML thread on "FunctionEvaluationException", that it was much better
to raise an exception than to rely on special values to detect problems. I think that the
same argument fits perfectly in this case.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message