Hi all,

Re: Ticket 854.

I wrote tests for the branch cuts for all complex arc* functions
in umathmodule. It turns out that all except arccosh were OK.
The formula for arcsinh was written in a non-standard form with
an unnecessary nc_neg, but this didn't affect the results.
I also wrote tests for checking values of the functions at infs and nans.

A patch for all of this is attached, with all currently non-passing
tests marked as skipped. I'd like to commit this if there are no objections.

Another thing I noticed is that the present implementations of
the complex functions are naive, so they over- and underflow earlier
than necessary:

>>> np.arcsinh(1e8)
19.113827924512311
>>> np.arcsinh(1e8 + 0j)
(inf-0j)
>>> np.arcsinh(-1e8 + 0j)
(-19.113827924512311-0j)

This particular thing in arcsinh occurs because of loss of precision
in intermediate stages. (In the version in my patch this loss of precision
is still present.)

It would be nice to polish these up. BTW, are there obstacles to using
the C99 complex functions when they are available? This would avoid
quite a bit of drudgework... As an alternative, we can probably steal
better implementations from Python's recently polished cmathmodule.c

   ***

Then comes a descent into pedantry: Numpy complex functions are not
C99 compliant in handling of the signed zero, inf, and nan. I don't
know whether we should comply with C99, but it would be nicer to have
these handled in a controlled way rather than as a byproduct of the
implementation chosen.

1)

The branch cuts for sqrt and arc* don't respect the negative zero:

>>> a = 1 + 0j
>>> np.sqrt(-a)
1j
>>> np.sqrt(-1 + 0j)
1j

The branch cut of the logarithm however does:

>>> np.log(-a)
-3.1415926535897931j
>>> np.log(-1 + 0j)
3.1415926535897931j

All complex functions in the C99 standard respect the negative zero
in their branch cuts. Do we want to follow?

I don't know how to check what Octave and Matlab do regarding this,
since I haven't figured out how to place a negative zero in complex
numbers in these languages. But at least in practice these languages
appear not to respect the sign of zero.

> a = 1 + 0j
> log(-a)
ans =  0.000000000000000 + 3.141592653589793i
> log(-1)
ans =  0.000000000000000 + 3.141592653589793i


2)

The numpy functions in general don't return C99 compliant results
at inf or nan. I wrote up some tests for checking these.

Do we want to fix these?