commons-dev mailing list archives

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

2012/8/23 Phil Steitz <phil.steitz@gmail.com>:
> 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 <gilles@harfang.homelinux.org>:
>>>>> On Thu, Aug 23, 2012 at 10:05:10AM +0200, Sébastien Brisard wrote:
>>>>>> Hi Luc,
>>>>>>
>>>>>> 2012/8/23 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>>>>>>> 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,
creating
>>>>>>>> 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"?
It
>>>>>>>> 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.
>
> +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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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

Sébastien


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message