Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <5037BC62.8090408@free.fr>
Date: Fri, 24 Aug 2012 19:39:46 +0200
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] UnexpectedNegativeIntegerException
References: <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>
 <20120823233544.GS24856@dusk.harfang.homelinux.org>
 <50372DDD.2050003@free.fr>
 <CAGRH7HqGLj0t8z4G_oq9GN+sL=113EDmsYxi7nRTdoiiXJd0Hw@mail.gmail.com>
 <20120824130459.GK20488@dusk.harfang.homelinux.org>
 <CAGRH7HonXqCwaCvS3j0jD=iocOxgPcNaHRwjLca7=5xcwbfZgA@mail.gmail.com>
 <20120824140934.GM20488@dusk.harfang.homelinux.org>
In-Reply-To: <20120824140934.GM20488@dusk.harfang.homelinux.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Le 24/08/2012 16:09, Gilles Sadowski a �crit :
> Hello S�bastien.
> 
>>>
>>>>> [...]
>>>>
>>>> I see that's another area where everyone has its own opinion because
>>>> of various experiences. I was previously in favor of exceptions, but
>>>> maybe it's too much for such a low-level component as a standard or
>>>> special function. So I am now convinced that NaN should be returned by
>>>> Gamma in case of invalid values. However, in the class Gamma, there
>>>> are other very low-level functions, which provide some approximations
>>>> of say Gamma(1 + x) - 1, *only in a specific range*. I believe that in
>>>> that case, an exception should be returned, as the function itself is
>>>> defined mathematically, it's only the approximation which is not
>>>> valid.
>>>
>>> I'm not so sure that an exception must be thrown. Of course the doc should
>>> say that the approximation is not valid beyond the specified range, but,
>>> since the function is defined, a user could be interested in experimenting
>>> with what happens beyond the limits.
>>>
>>
>> I'm not a big fan of that, but I can live with it. Instead of
>> exceptions, I'll place some assertions. Do you like it better?
> 
> No. We didn't agree that "assert" statements can be included in CM code.

I also don't like much assertions. The problem is that in some cases (I
know these are rare), some code need to be certified with respect to
some quality standard and code that can change is not allowed.
Typically, Apache Commons Math is now officially used in space critical
software (with a rather high criticity level). Adding more code paths
depending on configuration would be a testing nightmare for such uses.

Luc

> 
> [Personally, I don't think that it's a good idea that low-level utilities
> behave differently (with or without assertion enabled) when given the same
> inputs.]
> 
> Please just use exceptions, to provide less forgiving but more robust code.
> We can see later whether it makes sense to relax the access to the
> "dangerous" code...
> 
> 
> Best,
> Gilles
> 
>> I actually think it's a good compromise, since it allows a little bit
>> of debugging (provided assertions are enabled).
>>
>>>
>>>> NaN would be documented in the Javadoc. And since we are talking about
>>>> consistency, maybe it's better to be consistent with standard
>>>> functions, which do not raise exceptions but return NaNs instead.
>>>
>>> Maybe, but this only states that we want consistency with "something" (in
>>> this case, the behaviour of the functions of the standard Java Math class).
>>> It doesn't say why it is useful to return NaNs.
>>>
>>> We have thus a case where consistency is deemed good for its own sake. The
>>> same should hold for the code formatting issue.
>>>
>>>
>>> Regards,
>>> Gilles
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> S�bastien
>>
>>
>> ---------------------------------------------------------------------
>> 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