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 steven.daprano
Recipients Alex Monk, mark.dickinson, steven.daprano
Date 2015-06-12.14:48:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1434120534.2.0.00377825377563.issue24438@psf.upfronthosting.co.za>
In-reply-to
Content
I've found the same behaviour going back to Python 1.5.

I think what happens here is that (0+∞j)*1 evaluates the multiplication by implicitly coercing the int to a complex:

    (0+∞j)*(1+0j)
    => (0*1 + ∞j*1 + 0*0j + ∞j*0j)
    => (0-NAN + ∞j+0j)
    => (NAN + ∞j)

rather than using the "simple" way (1*0 + 1*∞j) => (0+∞j).

The problem here is that while there is no mathematical difference between multiplying by 1 or (1+0j), once you involve NANs and INFs, it does. So even though they give different answers, both methods are correct, for some value of "correct".

I don't see that this is necessarily a bug to be fixed, it might count as a change in behaviour needing to go through a deprecation period first. Perhaps it should be discussed on python-ideas first?

My personal feeling is that Python should multiply a complex by a non-complex in the "simple" way, rather than implicitly converting the int to a complex. Anyone who wants the old behaviour can easily get it by explicitly converting 1 to a complex first.

So I guess this is a +1 to "fixing" this.

(Oh, the same applies to the / operator.)
History
Date User Action Args
2015-06-12 14:48:54steven.dapranosetrecipients: + steven.daprano, mark.dickinson, Alex Monk
2015-06-12 14:48:54steven.dapranosetmessageid: <1434120534.2.0.00377825377563.issue24438@psf.upfronthosting.co.za>
2015-06-12 14:48:54steven.dapranolinkissue24438 messages
2015-06-12 14:48:53steven.dapranocreate