Issue 22544: Inconsistent cmath.log behaviour (original) (raw)

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:08 admin set github: 66734
2016-09-09 18:32:34 mark.dickinson set status: open -> closedresolution: wont fixmessages: + stage: resolved
2015-04-27 15:49:13 vstinner set nosy: - vstinner
2015-04-26 17:43:24 mark.dickinson set messages: +
2015-04-25 15:13:08 pbrod set nosy: + pbrodmessages: + versions: + Python 2.7
2014-10-03 11:09:30 mark.dickinson set assignee: mark.dickinson
2014-10-03 10:49:56 mark.dickinson set messages: +
2014-10-03 09:40:14 mark.dickinson set messages: +
2014-10-03 07:37:38 vstinner set nosy: + vstinner
2014-10-03 07🔞17 pitrou create