commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] UnexpectedNegativeIntegerException
Date Thu, 23 Aug 2012 19:00:56 GMT
On 8/23/12 5:37 AM, Luc Maisonobe wrote:
> Le 23/08/2012 13:37, Gilles Sadowski a écrit :
>> On Thu, Aug 23, 2012 at 12:35:18PM +0200, Sébastien Brisard wrote:
>>> Hi Gilles,
>>> 2012/8/23 Gilles Sadowski <>:
>>>> On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote:
>>>>> Hi Luc,
>>>>> 2012/8/23 Luc Maisonobe <>:
>>>>>> Le 23/08/2012 05:16, Sébastien Brisard a écrit :
>>>>>>> Hi,
>>>>>>> in MATH-849, I have proposed an implementation of Gamma(x)
>>>>>>> (previously, class Gamma had only logGamma(x)). Gamma(x) is not
>>>>>>> defined for x negative integer. In such instances, I would like
>>>>>>> throw an exception instead of returning Double.NaN. However,
>>>>>>> a new exception in o.a.c.m.exception seems exagerated, since
it's very
>>>>>>> unlikely that this exception should be used elsewhere (or maybe).
>>>>>>> Should I define a nested exception instead [1]?
>>>>>>> What do you think of the name "UnexpectedNegativeIntegerException"?
>>>>>>> does not really match the pattern of already defined exceptions,
but I
>>>>>>> can't find a better name.
>>>>>> Don't we already have NotPositiveException?
>>>>>> Luc
>>>>> We do, but Gamma is defined for all negative values, except integer ones...
>>>> I think that in some circumstances, it might be useful to not throw
>>>> exceptions...
>>>> FastMath's "log" returns NaN for negative input.
>>> then I guess that logGamma(x) should also return NaN if x <= 0?
>> Anyways, that's what it does currently.
>>> I have to say I do not really like this option.
>> So did you intend to change that?
>>> My life would
>>> sometimes be much easier if NaNs didn't exist... the good old days of
>>> the "floating-point error".

We have different memories - I am old enough to remember wasting
real money due to jobs failing on "floating point checks" when I
would have preferred to have computations complete and return NaN
(which had not been invented yet).

>> IIRC NaN could be useful for example in an optimization algorithm; excerpt
>> from Kahan:
>> ---
>> [...] NaNs is an opportunity ( not obligation ) for software ( especially
>> when searching ) to follow an unexceptional path ( no need for exotic
>> control structures ) to a point where an exceptional event can be appraised
>> after the event, when additional evidence may have accrued. [...]
>> ---
>> I do not say that Commons Math should prefer NaN over throwing exceptions.
> If the choice is allowed would really prefer NaN for such cases.

>> Maybe that it depends on how high-level an application is (i.e. if there are
>> already calls to methods that could throw exceptions, then an algorithm that
>> would not use try/catch to protect itself would fail anyway).
>> If we want Commons Math to allow taking advantage of NaNs, it would probably
>> need to be updated so that a lot of precondition checks ought to be removed
>> (but this will likely lead to reduced robustness in some applications that
>> do not do their own checks...).
> This would clearly be cumbersome for users.
> Since we have changed our exception hierarchy, we don't have a single
> root anymore, so users simply cannot catch all exception we throw at
> once, they have to check every single type, and make sure they are
> thrown by themselves without any help from compiler.
> Just adding new exceptions is too much, we have already gone too far
> this way.

+1 and the fact that all exceptions are unchecked makes it even
harder for client apps as the compiler will not help / force them. 
There is a reason that NaNs exist.  It is much cheaper to return a
NaN than to raise (and force the client to handle) an exception. 
This is not precise and probably can't be made so, but I have always
looked at things more or less like this:

0) IAE (which I see no need to specialize as elaborately as we have
done in [math]) is for clear violation of the documented API
contract.  The actual parameters "don't make sense" in the context
of the API.
1) NaN can be returned as the result of a computation which, when
started with legitimate arguments, does not result in a
representable value.

The problem is that contracts can often be written so that instances
of 1) are turned into instances of 0).  Gamma(-) is a great
example.  The singularities at negative integers could be viewed as
making negative integer arguments "illegal" or "nonsense" from the
API standpoint, or legitimate arguments for which no well-defined,
representable value can be returned.  Personally, I would prefer to
get NaN back from this function and just point out the existence of
the singularities in the javadoc.


> best regards,
> Luc
>> In the absence of strong arguments, the choice should probably match the
>> usage of current Commons Math's users. [This is an issue somewhat similar to
>> the one that led to stop using checked exceptions.]
>> Best regards,
>> Gilles
>> P.S. How do you test that the input is a negative integer?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message