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
