pow() for complex numbers is rough around the edges

[mattip]

BPO	15996
Nosy	@rhettinger, @terryjreedy, @jcea, @mdickinson, @alex, @serhiy-storchaka, @mattip
Files	rcomplex_testcases2.txt: test cases for complex_power

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2012-09-20.22:00:27.599>
labels = ['interpreter-core', 'type-feature']
title = 'pow() for complex numbers is rough around the edges'
updated_at = <Date 2021-10-22.08:24:05.162>
user = 'https://github.com/mattip'

bugs.python.org fields:

activity = <Date 2021-10-22.08:24:05.162>
actor = 'mark.dickinson'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2012-09-20.22:00:27.599>
creator = 'mattip'
dependencies = []
files = ['27238']
hgrepos = []
issue_num = 15996
keywords = []
message_count = 11.0
messages = ['170856', '170866', '170870', '170891', '170951', '171009', '171048', '199729', '199752', '404646', '404727']
nosy_count = 7.0
nosy_names = ['rhettinger', 'terry.reedy', 'jcea', 'mark.dickinson', 'alex', 'serhiy.storchaka', 'mattip']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue15996'
versions = ['Python 3.4']

[mattip]

complex(1., 0.) ** complex(float('inf'), 0.) raises a ZeroDivisionError. In general, complex_power() needs to handle more corner cases. Barring a clear standard for pow() in C99, the documentation for pow 3 in glibc
http://www.kernel.org/doc/man-pages/online/pages/man3/pow.3.html
seems solid for a start, however it only describes behaviour for float/double values.

Where would be an appropriate place to add tests? I propose adding a test-case file similar to cmath_testcases.txt (attached) and a test runner similar to test_cmath.py

[mdickinson]

Well, C99 covers pow for *real* numbers just fine; it's complex numbers where no-one wants to pin down what the behaviour should be. So I don't think we need the man page reference.

If we're writing tests for complex pow, we might also want to consider adding tests for multiplication and division; those aren't entirely trivial either for special cases.

I do agree that (for the most part), complex pow applied to arguments with zero imaginary part should behave like regular float pow. There are some cases where it's clear what the behaviour should be, and others that are murkier.

E.g., for a positive real z and arbitrary complex w, the special cases for z**w should behave in the same way as for exp for z > 0, and with some reflection of that behaviour for 0 < z < 1; 1**w should always be 1.

For nonzero finite values it's straightforward: we just want to compute the best approximation to exp(w * log(z)), with the branch cut for the log along the negative real axis as usual.

But there are a *lot* of special cases to think about. Consider that each real or imaginary part of the input is either:

(1) -infinity,
(2) -finite,
(3) -0.0
(4) +0.0
(5) +finite
(6) +infinity
(7) nan

and that we've got 2 complex inputs, or in effect 4 real inputs. This divides our argument space into 7**4 = 2401 pieces. With luck we can find rules that cover lots of those pieces at once, but it's still going to be a long job.

It doesn't help that it isn't particularly clear what the underlying mathematical model should be. For floats, we can think about the two-point compactification of the real line (okay, with a doubled zero, which messes things up a little bit), which is a fairly sane space to work in.

[serhiy-storchaka]

Well, C99 covers pow for *real* numbers just fine; it's complex numbers
where no-one wants to pin down what the behaviour should be.

C99 contains cpow. Perhaps we should use conditional compilation?

[mdickinson]

C99 contains cpow. Perhaps we should use conditional compilation?

I dread to think what horrors lurk in OS math library implementations of cpow; I suspect we'd soon find out, if we had used cpow and have any tests at all for special cases.

OS math libraries are bad enough at *float* math, let alone complex; I'd rather not depend on them unless we have to. And given that at least on Windows we need our own complex pow implementation anyway, I'd prefer to use the same code on all platforms, so that we have at least some degree of consistency from platform to platform.

[terryjreedy]

Given that
>>> 1.0**float('inf'), 1.0**float('-inf')
(1.0, 1.0)

works,

>>> (1.0+0j)**(float('inf') + 0j)
Traceback ...
ZeroDivisionError: 0.0 to a negative or complex power

(and same for ('-inf') seems like a clear bug in raising an exception, let alone a clearly wrong exception. Clarification of murky cases, if it changes behavior, might be an enhancement.

[mdickinson]

(1.0+0j)**(float('inf') + 0j)

Oddly enough, this is nan+nanj on OS X. I haven't investigated what the difference is due to---probably something to do with the errno results.

[mdickinson]

Reclassifying this as an enhancement; I don't think it's appropriate to rewrite complex_pow for the bugfix releases.