Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.

Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

Logged In: YES 
user_id=31435

Assigned to me.

Logged In: YES 
user_id=31435

These are old bugs in complex_pow() and friends.  Please 
give current CVS a try!  Changes made in

Objects/complexobject.c; new revision: 2.55:

1. Raising 0 to a negative power isn't a range error, it's 
a domain error, so changed c_pow() to set errno to EDOM in
that case instead of ERANGE.

2. Changed complex_pow() to:

A. Use the Py_ADJUST_ERANGE2 macro to try to clear errno of
a spurious ERANGE error due to underflow in the libm pow()
called by c_pow().

B. Produce different exceptions depending on the errno
value:

i) For errno==EDOM, raise ZeroDivisionError instead of
ValueError.  This is for consistency with the non-complex 
cases 0.0**-2 and 0**-2 and 0L**-2.

ii) For errno==ERANGE, raise OverflowError.

Logged In: YES 
user_id=11850

Perhaps these are old bugs, but I never ran into them before. I will try the CVS as soon as I can. Given my bad track record with downloads from SourceForge, that might be a while...

For the moment, I propose to reactivate -lieee for Linux again in 2.2.1. I have done lots of tests with that combination recently, with no adverse effects.

Logged In: YES 
user_id=31435

It would help if you simply tried your example under 2.1 -- 
I don't have your system, and can't try it for you.  It's 
extraordinarily risky making any last-second change to a 
bugfix release, and whether it's an old bug feeds into the 
tradeoff calculation.

Enabling -lieee at the last second isn't something I'll do 
without lots of people swearing it doesn't hurt anything on 
their boxes.  Not all systems act the same way in the 
presence of -lieee.  The change I did make is in our C 
code, where I have a good chance of guessing what various C 
compilers will do; -lieee does whatever a platform feels 
like doing, and there's no standard to constrain it.

Logged In: YES 
user_id=6656

I've ported Tim's fix from the trunk.  It will be in 2.2.1c2
which will probably be released tomorrow.

Can this be closed?

> For the moment, I propose to reactivate -lieee 
> for Linux again in 2.2.1.

No chance.

Logged In: YES 
user_id=11850

The bug is indeed old, the behaviour is the same under 2.1.2, as I just checked.

I will try 2.2.1c2 as soon as it is out.

Logged In: YES 
user_id=31435

Thanks for the 2.1 confirmation, Konrad!

As Michael asked, closing as (presumed) Fixed so this 
doesn't show up as a showstopper 2.2.1 issue anymore.  
Konrad, if the example still fails under 2.2.1c2, leave a 
note here and I'll reopen this.

Michael, are you intending a second release candidate?  Or 
is this really 2.2.1 final?