commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sébastien Brisard <>
Subject Re: [math] UnexpectedNegativeIntegerException
Date Thu, 23 Aug 2012 19:08:30 GMT
thanks for all these answers.

2012/8/23 Phil Steitz <>:
> 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 to
>>>>>>>> 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
>>>>>>>> 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
>>>>> 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.
> +1
>>> 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.
> Phil
>> 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:

So, NaN it is! And I'll keep the present behavior
forGamma.logGamma(x): return NaN for x <= 0.


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

View raw message