Hi Gilles, 2012/8/24 Gilles Sadowski <gil...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > Sébastien --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
