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 <gil...@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.maison...@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". > > 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. 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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
