[issue15996] pow() for complex numbers is rough around the edges

[Mark Dickinson]

Mark Dickinson  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Terry J. Reedy]

Terry J. Reedy  added the comment:

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?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Mark Dickinson]

Mark Dickinson added the comment:

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)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Raymond Hettinger]

Raymond Hettinger added the comment:

 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.

--
nosy: +rhettinger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Mark Dickinson]

Mark Dickinson added the comment:

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

--
type: behavior - enhancement
versions:  -Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Jesús Cea Avión]

Changes by Jesús Cea Avión j...@jcea.es:


--
nosy: +jcea
stage: test needed - 
type: enhancement - behavior

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Jesús Cea Avión]

Changes by Jesús Cea Avión j...@jcea.es:


--
stage:  - test needed
type: behavior - enhancement

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Mark Dickinson]

Mark Dickinson added the comment:

 (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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Serhiy Storchaka]

Changes by Serhiy Storchaka storch...@gmail.com:


--
nosy: +storchaka

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Mark Dickinson]

Mark Dickinson added the comment:

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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

 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?

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Mark Dickinson]

Mark Dickinson added the comment:

 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.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Terry J. Reedy]

Terry J. Reedy added the comment:

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.

--
nosy: +terry.reedy
stage:  - test needed
versions: +Python 3.3, Python 3.4

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[mattip]

New submission from 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

--
components: Interpreter Core
files: rcomplex_testcases2.txt
messages: 170856
nosy: mark.dickinson, mattip
priority: normal
severity: normal
status: open
title: pow() for complex numbers is rough around the edges
type: behavior
Added file: http://bugs.python.org/file27238/rcomplex_testcases2.txt

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15996] pow() for complex numbers is rough around the edges

[Alex Gaynor]

Changes by Alex Gaynor alex.gay...@gmail.com:


--
nosy: +alex

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15996
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com