[
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.
