Hi, I was involved in a similar debate on a different project, and we came to the conclusion that (double -> double) methods in Java should return NaN in the case of invalid arguments, rather than throw Exceptions.
Our reasoning was by analogy with how IEEE 754 floating-point exceptions are handled by Java. Obviously, the definition of a floating-point exception is quite different from a Java exception. But anyway, our question was, how should raising an exception in the floating-point world map to throwing an exception in Java? The core Java libraries effectively behave as if all floating-point traps are disabled*: Overflow results in an infinity, underflow in subnormal/zero, square root of negative returns NaN, etc. Based on this, we decided that returning NaN is the “best” behavior, since this is what IEEE spec says to do when in the invalid operation flag is disabled. Fran. * = We did discuss having a kind of floating-point signal policy that would change the behavior from returning a default value to throwing a (Java) exception when these floating-point exceptions were detected. But this would be a complex implementation problem, not least because incorporating this into existing numerical libraries would be difficult to impossible. > On Nov 29, 2019, at 11:48 AM, Gilles Sadowski <gillese...@gmail.com> wrote: > > Hello. > > For all implemented distributions, what convention should be adopted > when methods > * density(x) > * logDensity(x) > * cumulativeProbability(x) > are called with "x" out of the "support" bounds? > > Currently some (but not all[1]) are documented to return "NaN". > An alternative could be to throw an exception. > > Regards, > Gilles > > [1] https://issues.apache.org/jira/projects/MATH/issues/MATH-1503 > > --------------------------------------------------------------------- > 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
