Message 105515 - Python tracker

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Content
A bit more explanation:  Python takes account of the sign of zero when deciding which side of the branch cut a value lies, which is the proper thing to do when you have signed zeros available (according to the likes of Kahan, anyway);  I suspect that numpy isn't doing that, but is treating all values that lie directly on a branch in the same way.

In this case there's a branch cut from -1j down to -1j*inf.  Values just to the right of that branch cut (i.e., with positive real part) should have a result with positive real part;  values just to the left of it should have negative real part:

Some results (using complex() to create the values, since other ways of creating complex numbers are prone to changing the sign of a zero):

>>> asinh(complex(0.0, -2.0))
(1.3169578969248166-1.5707963267948966j)
>>> asinh(complex(1e-10, -2.0))
(1.3169578969248166-1.5707963267371616j)
>>> asinh(complex(-0.0, -2.0))
(-1.3169578969248166-1.5707963267948966j)
>>> asinh(complex(-1e-10, -2.0))
(-1.3169578969248166-1.5707963267371616j)

So the cmath module is working as intended here.  numpy may or may not be working as intended:  I don't know how much they care about branch cut continuity.