Mark Dickinson <dicki...@gmail.com> added the comment: 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1381> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
