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.

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.
History
Date User Action Args
2010-05-11 14:00:17mark.dickinsonsetrecipients: + mark.dickinson, gvanrossum, loewis, jcea, alanmcintyre, inducer, christian.heimes, bins
2010-05-11 14:00:16mark.dickinsonsetmessageid: <1273586416.86.0.100876062303.issue1381@psf.upfronthosting.co.za>
2010-05-11 14:00:15mark.dickinsonlinkissue1381 messages
2010-05-11 14:00:14mark.dickinsoncreate