Christian Heimes added the comment: Mark Dickinson wrote: > For atanh(1): raising OverflowError is actually consistent with what > currently happens. > The only singularity that's already present in math is log(0), and it seems > that that > raises OverflowError on OS X, Linux and Windows... I wonder whether this is > what Tim > meant to say?
But on Linux atanh(1) sets errno = EDOM and raises a ValueError. Either the outcome is not consistent or the libm developers have a different philosophy than Time and you. *g* > For acosh(0): you're right, and I'm wrong---this should definitely return a > NaN and set > errno. I guess that dividing 0 by 0 doesn't set errno on Windows. Okay: > let's set it > directly there. I'm not an expert on IEEE754 and NaN but I guess "Signaling NaN" also means it sets errno. Personally I'm not interested in reimplementing or fixing Windows' mathematical library (although it's tempting *g*) but to get the results right for our purpose. You are right, we should try to mimic the C99 standard whenever it is possible. But it's more important to get the functions of our math module right. > I do still think that asinh(nan), atanh(nan) and acosh(nan) should return nan > and not > raise any exceptions, just for the sake of consistency with Linux/OS X and > with the other > libm functions. Yes, it makes perfectly sense and glibc's libm already does the right thing. However Windows screws up again so I've to fix the function call manually. Damn you Windows! I inserted the four lines in mathmodule.c:math_1() and something similar in math_2() to fix Windows. #ifndef __GNUC__ /* Windows et al */ if (Py_IS_NAN(x)) return PyFloat_FromDouble(x+x); #endif > I guess I don't really care about asinh(+/-inf), etc: an infinite return > value will be > caught by the stuff in math_1 anyway. Are you fine with OverflowError? I'm going to create a branch for your work. It's getting tedious sending large patches back and forth. Christian __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1640> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com