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 (athena.apache.org: local policy)
Date: Fri, 24 Aug 2012 15:04:59 +0200
From: Gilles Sadowski <gilles@harfang.homelinux.org>
To: dev@commons.apache.org
Subject: Re: [math] UnexpectedNegativeIntegerException
Message-ID: <20120824130459.GK20488@dusk.harfang.homelinux.org>
Mail-Followup-To: dev@commons.apache.org
References: <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>
 <20120823233544.GS24856@dusk.harfang.homelinux.org>
 <50372DDD.2050003@free.fr>
 <CAGRH7HqGLj0t8z4G_oq9GN+sL=113EDmsYxi7nRTdoiiXJd0Hw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAGRH7HqGLj0t8z4G_oq9GN+sL=113EDmsYxi7nRTdoiiXJd0Hw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-DCC-scarlet.be-Metrics: sif 20002; Body=1 Fuz1=1 Fuz2=1
X-Virus-Scanned: clamav-milter 0.97.1-exp at sif
X-Virus-Status: Clean
X-Virus-Checked: Checked by ClamAV on apache.org

Hi.

> > [...]
> 
> 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.

> 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