Hello Sébastien. > > > > > > [...] > > > > > > 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?
No. We didn't agree that "assert" statements can be included in CM code. [Personally, I don't think that it's a good idea that low-level utilities behave differently (with or without assertion enabled) when given the same inputs.] Please just use exceptions, to provide less forgiving but more robust code. We can see later whether it makes sense to relax the access to the "dangerous" code... Best, Gilles > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
