Message105515
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. |
|
Date |
User |
Action |
Args |
2010-05-11 14:00:17 | mark.dickinson | set | recipients:
+ mark.dickinson, gvanrossum, loewis, jcea, alanmcintyre, inducer, christian.heimes, bins |
2010-05-11 14:00:16 | mark.dickinson | set | messageid: <1273586416.86.0.100876062303.issue1381@psf.upfronthosting.co.za> |
2010-05-11 14:00:15 | mark.dickinson | link | issue1381 messages |
2010-05-11 14:00:14 | mark.dickinson | create | |
|