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: ```python assignee = None closed_at = None created_at = labels = ['interpreter-core', 'type-feature'] title = 'pow() for complex numbers is rough around the edges' updated_at = user = 'https://github.com/mattip' ``` bugs.python.org fields: ```python activity = actor = 'mark.dickinson' assignee = 'none' closed = False closed_date = None closer = None components = ['Interpreter Core'] creation = 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.

[mdickinson]

See also http://stackoverflow.com/q/18243270/270986 , which points out the following inconsistencies:

>>> 1e300 ** 2
OverflowError: (34, 'Result too large')
>>> 1e300j ** 2
OverflowError: complex exponentiation
>>> (1e300 + 1j) ** 2
OverflowError: complex exponentiation
>>> (1e300 + 1e300j) ** 2
(nan+nanj)

[rhettinger]

OS math libraries are bad enough at *float* math, let alone complex; I'd rather not depend on them unless we have to.

This makes good sense. We should control how the special cases resolve and not be subject the whims of various C libraries.

[terryjreedy]

In Windows, I now get the Mark's macOS result instead of the Z.D.Error.

>>> (1.0+0j)**(float('inf') + 0j)
(nan+nanj)

Has there been a revision of complex ** on another issue such that this one is obsolete?

[mdickinson]

See also discussion in bpo-44970, which is closed as a duplicate of this issue.

[skirpichev]

See also https://github.com/python/cpython/issues/117999. We should remember, that there is a specialization for small integer powers. That algorithm doesn't match generic case (due to different arrangement of parenthesis).

While this specialization has a measurable performance boost, I think we can consider to revert it for correctness.

I dread to think what horrors lurk in OS math library implementations of cpow

Hmm, I just run cmath_testcases.txt (unfortunately, it has no pow() tests) with libm's complex functions. There are 14 failures, some might be CPython's fault, as things were changed in recent C standards.

script and test output

```python # a.py import ctypes import math from test.test_math import parse_testfile c = parse_testfile('Lib/test/mathdata/cmath_testcases.txt') libm = ctypes.CDLL('libm.so.6') c_funcs = ['cexp', 'clog', 'cpow', 'csqrt', 'cabs', 'csin', 'ccos', 'ctan', 'casin', 'cacos', 'catan', 'csinh', 'ccosh', 'ctanh', 'casinh', 'cacosh', 'catanh'] for f in c_funcs: fun = getattr(libm, f) fun.argtypes = [ctypes.c_double_complex] fun.restype = ctypes.c_double_complex def _isclose(a, b, rel_err = 2e-15, abs_err = 5e-323): if math.isnan(a): if math.isnan(b): return True return False if not a and not b: return math.copysign(1., a) == math.copysign(1., b) return math.isclose(a, b, rel_tol=rel_err, abs_tol=abs_err) for id, fn, ar, ai, er, ei, flags in c: cname = 'c'+fn if cname not in c_funcs: continue actual = getattr(libm, cname)(complex(ar, ai)) expected = complex(er, ei) if 'ignore-real-sign' in flags: actual = complex(abs(actual.real), actual.imag) expected = complex(abs(expected.real), expected.imag) if 'ignore-imag-sign' in flags: actual = complex(actual.real, abs(actual.imag)) expected = complex(expected.real, abs(expected.imag)) if not (_isclose(actual.real, expected.real) and _isclose(actual.imag, expected.imag)): print(id, fn, complex(ar, ai), expected, actual, flags) ``` ``` $ ./python ~/a.py acosh1006 acosh nanj (nan+nanj) (nan+1.5707963267948966j) [] acosh1008 acosh (-0+nanj) (nan+nanj) (nan+1.5707963267948966j) [] tanh1001 tanh infj (nan+nanj) nanj ['invalid'] tanh1003 tanh nanj (nan+nanj) nanj [] tanh1018 tanh -infj (nan+nanj) nanj ['invalid'] tanh1031 tanh (-0-infj) (nan+nanj) (-0+nanj) ['invalid'] tanh1033 tanh (-0+nanj) (nan+nanj) (-0+nanj) [] tanh1044 tanh (-0+infj) (nan+nanj) (-0+nanj) ['invalid'] tan1001 tan (-inf+0j) (nan+nanj) (nan+0j) ['invalid'] tan1003 tan (nan+0j) (nan+nanj) (nan+0j) [] tan1018 tan (inf+0j) (nan+nanj) (nan+0j) ['invalid'] tan1031 tan (inf-0j) (nan+nanj) (nan-0j) ['invalid'] tan1033 tan (nan-0j) (nan+nanj) (nan-0j) [] tan1044 tan (-inf-0j) (nan+nanj) (nan-0j) ['invalid'] ```

So, at least glibc's math library isn't too bad.

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.

No. It's same for C code too.

```c #include #include #include int main(void) { double complex b = CMPLX(1, 0), e = CMPLX(INFINITY, 0); double complex z = cpow(b, e); printf("(%lf%+lfj)\n", creal(z), cimag(z)); return 0; } ``` ``` $ gcc-12 a.c -std=c11 -lm && ./a.out (nan+nanj) ```

Annex G says that for cpow(x, y): errors and special cases are handled as if the operation is implemented by cexp(y*clog(x)), except that the implementation is allowed to "treat special cases more carefully". clog(1+0j)==0j and complex('(inf+0j)')*complex(0,0) is nan+nanj. So, this seems to be correct.

See also http://stackoverflow.com/q/18243270/270986 , which points out the following inconsistencies:

(1e300 + 1e300j) ** 2

Now that results in OverflowError in my branch https://github.com/python/cpython/pull/118000. Inconsistent result is again due to specialization for small integer powers.