Accepted (but reluctantly; see below), and assigned back to Guido for checkin.
cmathmodule is not production quality, and this patch isn't either, but its asinh and acosh are better than what's there now.
The author avoided some of the numerical foolishness in the original, but didn't avoid all of it. For example, it's harder to get asinh to do something ridiculous now than it was before, but still possible:
>>> cmath.acosh(1e200)
(461.210165779+0j)
>>> cmath.asinh(1e200)
(1.#INF+0j)
>>>
asinh should have returned something approximately equal to what acosh returned.
That may not be the patch's problem, though! I suspect that's due to one of the module's other functions that's too naive about the limits of floating point. In any case, it is *much* easier to provoke the current cmath functions into cases like this one.
Another possible problem has to do with principal values. My reference books are in storage, so about the best I can do right now is compare what this code does to Macsyma (which I have on my laptop). The acosh in this patch often returns the negative of what Macysma computes. For example,
>>> cmath.acosh(-1-1j)
(1.06127506191-2.23703575929j)
>>>
Macsyma returns the negation of that. On the other hand, the *original* acosh doesn't agree with Macsyma on some signs where this acosh does. So call this one a wash.
I may have mentioned this before <wink>: robust math libraries are extremely difficult to get right. It would take several months to write a production-quality cmath module from scratch, which is several months more than were devoted to Python's current cmath <wink>. I vote we check this in anyway (since it *is*, overall, an improvement), and look into borrowing some other language's complex math library later (note in particular that C9X adds complex numbers and these functions on them, so if we sit on our asses long enough, we can inherit libc's!).
|
➜
