Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of
 SRS0=tD/E=GX=m4x.org=sebastien.brisard@bounces.m4x.org designates
 129.104.30.34 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <50367DE8.20909@gmail.com>
References: 
 <CAGRH7HrSfBLrSpuV1ofNyLEDD4oHCGU9LB0HQcoxiR6xDkRNdQ@mail.gmail.com>
	<5035DEE0.6000705@free.fr>
	<CAGRH7Hr2FW6PdpLH5ZSQmb5PCm+4YdZuukno69A-GyB7ZR2xKg@mail.gmail.com>
	<20120823102450.GG20488@dusk.harfang.homelinux.org>
	<CAGRH7Hpmm64P_gORt3jjgzVmy+FR+GjDkjAsv5SyV=6ovwdw0g@mail.gmail.com>
	<20120823113754.GH20488@dusk.harfang.homelinux.org>
	<50362413.8070205@free.fr>
	<50367DE8.20909@gmail.com>
Date: Thu, 23 Aug 2012 21:08:30 +0200
Message-ID: 
 <CAGRH7HpncqqtzVUrsqWN4r9HLkW-Wpq-EJSJot0F6vOoEHCfvQ@mail.gmail.com>
Subject: Re: [math] UnexpectedNegativeIntegerException
From: =?ISO-8859-1?Q?S=E9bastien_Brisard?= <sebastien.brisard@m4x.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 =E9crit :
>>> On Thu, Aug 23, 2012 at 12:35:18PM +0200, S=E9bastien Brisard wrote:
>>>> Hi Gilles,
>>>>
>>>> 2012/8/23 Gilles Sadowski <gilles@harfang.homelinux.org>:
>>>>> On Thu, Aug 23, 2012 at 10:05:10AM +0200, S=E9bastien Brisard wrote:
>>>>>> Hi Luc,
>>>>>>
>>>>>> 2012/8/23 Luc Maisonobe <Luc.Maisonobe@free.fr>:
>>>>>>> Le 23/08/2012 05:16, S=E9bastien Brisard a =E9crit :
>>>>>>>> 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, creat=
ing
>>>>>>>> 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, b=
ut 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 <=3D 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; exce=
rpt
>>> from Kahan:
>>> ---
>>> [...] NaNs is an opportunity ( not obligation ) for software ( especial=
ly
>>> when searching ) to follow an unexceptional path ( no need for exotic
>>> control structures ) to a point where an exceptional event can be appra=
ised
>>> after the event, when additional evidence may have accrued. [...]
>>> ---
>>>
>>> I do not say that Commons Math should prefer NaN over throwing exceptio=
ns.
>> 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 ther=
e 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 pro=
bably
>>> need to be updated so that a lot of precondition checks ought to be rem=
oved
>>> (but this will likely lead to reduced robustness in some applications t=
hat
>>> 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 th=
e
>>> usage of current Commons Math's users. [This is an issue somewhat simil=
ar 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 <=3D 0.

S=E9bastien


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