commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From S├ębastien Brisard <sebastien.bris...@m4x.org>
Subject Re: [math] UnexpectedNegativeIntegerException
Date Fri, 24 Aug 2012 13:39:11 GMT
Hi Gilles,

2012/8/24 Gilles Sadowski <gilles@harfang.homelinux.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.
>

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?
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


Mime
View raw message