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