Message105515
| Author |
mark.dickinson |
| Recipients |
alanmcintyre, bins, christian.heimes, gvanrossum, inducer, jcea, loewis, mark.dickinson |
| Date |
2010年05月11日.14:00:14 |
| SpamBayes Score |
0.0021968642 |
| Marked as misclassified |
No |
| Message-id |
<1273586416.86.0.100876062303.issue1381@psf.upfronthosting.co.za> |
| In-reply-to |
| 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. |
|