You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Luc Maisonobe (JIRA)" <ji...@apache.org> on 2010/11/07 11:52:09 UTC

[jira] Commented: (MATH-433) Signal overflow by raising an exception

    [ https://issues.apache.org/jira/browse/MATH-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929326#action_12929326 ] 

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: https://issues.apache.org/jira/browse/MATH-433
>             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.