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.

classification
Title: Inconsistent cmath.log behaviour
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.4, Python 3.5, Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: eric.smith, lemburg, mark.dickinson, pbrod, pitrou, stutzbach
Priority: low Keywords:

Created on 2014-10-03 07:18 by pitrou, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (6)
msg228307 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-10-03 07:18
>>> inf = float('inf')
>>> z = complex(-0.0, -inf)
>>> cmath.log(z)
(inf-1.5707963267948966j)
>>> cmath.log10(z)
(inf-0.6821881769209206j)
>>> cmath.log(z, 10)
(inf+nan*j)
msg228319 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-10-03 09:40
I think this is mostly unavoidable: cmath.log(z, 10) is a compound operation that does the equivalent of cmath.log(z) / cmath.log(10), while cmath.log10 is doing everything at once.

If anything, this is a problem in how complex division is done: it's arguable that division by a complex number with zero imaginary part should be special-cased here.

>>> inf = float('inf')
>>> z = complex(-0.0, -inf)
>>> cmath.log(10)
(2.302585092994046+0j)
>>> cmath.log(z)
(inf-1.5707963267948966j)
>>> cmath.log(z) / cmath.log(10)
(inf+nanj)

A simpler example just involving division:

>>> complex(2.0, inf) / 2.0   # expect 1 + infj.
(nan+infj)
msg228320 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2014-10-03 10:49
One other option that doesn't involve changing the behaviour of complex division would be to special-case `cmath.log` in the case when the second argument is a float or an int.
msg242016 - (view) Author: Per Brodtkorb (pbrod) Date: 2015-04-25 15:13
This is not only a problem for division. It also applies to multiplication as exemplified here:

>>> complex(0,inf)+1  # expect 1 + infj
Out[16]: (1+infj)

>>> (complex(0,inf)+1)*1  # expect 1 + infj
Out[17]: (nan+infj)

>>> complex(inf, 0) + 1j  # expect inf + 1j
Out[18]: (inf+1j)

>>> (complex(inf, 0)+1j)*1  # expect inf + 1j
Out[19]: (inf, nanj)
msg242068 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2015-04-26 17:43
Per: yes, that's true. I don't think changing either division or multiplication is the way forward for this issue, though; I'd rather implement the less invasive change where `cmath.log` special-cases the situation where its second argument is real and positive.
msg275376 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2016-09-09 18:32
Closing as "won't fix". Two-argument log is already a rather unnatural beast to have in the cmath module, and I find it hard to imagine any real-world use-case caring about what happens for two-argument complex log applied to infinities or nans.
History
Date User Action Args
2022-04-11 14:58:08adminsetgithub: 66734
2016-09-09 18:32:34mark.dickinsonsetstatus: open -> closed
resolution: wont fix
messages: + msg275376

stage: resolved
2015-04-27 15:49:13vstinnersetnosy: - vstinner
2015-04-26 17:43:24mark.dickinsonsetmessages: + msg242068
2015-04-25 15:13:08pbrodsetnosy: + pbrod

messages: + msg242016
versions: + Python 2.7
2014-10-03 11:09:30mark.dickinsonsetassignee: mark.dickinson
2014-10-03 10:49:56mark.dickinsonsetmessages: + msg228320
2014-10-03 09:40:14mark.dickinsonsetmessages: + msg228319
2014-10-03 07:37:38vstinnersetnosy: + vstinner
2014-10-03 07:18:17pitroucreate