Hi, thanks for all these answers. 2012/8/23 Phil Steitz <phil.ste...@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 <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". > > 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-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 >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
