This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients alex, mark.dickinson, mattip, serhiy.storchaka
Date 2012-09-21.07:57:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1348214260.92.0.717304190766.issue15996@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2012-09-21 07:57:41mark.dickinsonsetrecipients: + mark.dickinson, alex, serhiy.storchaka, mattip
2012-09-21 07:57:40mark.dickinsonsetmessageid: <1348214260.92.0.717304190766.issue15996@psf.upfronthosting.co.za>
2012-09-21 07:57:40mark.dickinsonlinkissue15996 messages
2012-09-21 07:57:39mark.dickinsoncreate