complex constructor loses signs of zeros

[mdickinson]

BPO	1507
Nosy	@gvanrossum, @mdickinson
Files	complex_new.patch

^{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:

assignee = None
closed_at = <Date 2009-02-11.14:02:34.718>
created_at = <Date 2007-11-27.22:25:12.745>
labels = []
title = 'complex constructor loses signs of zeros'
updated_at = <Date 2009-02-11.14:02:34.717>
user = 'https://github.com/mdickinson'

bugs.python.org fields:

activity = <Date 2009-02-11.14:02:34.717>
actor = 'mark.dickinson'
assignee = 'anthonybaxter'
closed = True
closed_date = <Date 2009-02-11.14:02:34.718>
closer = 'mark.dickinson'
components = []
creation = <Date 2007-11-27.22:25:12.745>
creator = 'mark.dickinson'
dependencies = []
files = ['8815']
hgrepos = []
issue_num = 1507
keywords = []
message_count = 3.0
messages = ['57891', '57893', '81643']
nosy_count = 3.0
nosy_names = ['gvanrossum', 'anthonybaxter', 'mark.dickinson']
pr_nums = []
priority = 'high'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1507'
versions = ['Python 2.5']

[mdickinson]

In Python2.5 and the current trunk, construction of a complex number from two floats
loses the negative sign of a negative zero in the imaginary part.

>>> complex(-0., 0.).real  # behaves as expected
-0.0
>>> complex(0., -0.).imag  # loses sign of zero
0.0

There are situations where it's important to preserve the sign of zero (typically
when doing calculations involving functions with branch cuts); there are probably
platforms where this is difficult for one reason or another, but on a platform that
complies with all the usual standards I can't see any reason for Python not to
preserve the signs of zeros, provided that it's straightforward to do so.

The attached patch changes the complex constructor so that if x and y are numeric
and neither x nor y is complex (or a subclass of complex) then complex(x, y) simply
places x into the real part of the complex number and y into the imaginary part.
For someone who doesn't care about the sign of zeros, this patch will have no
noticeable effect. Similarly, on a system that does not have full hardware or
system support for signed zeros, this patch should be harmless. Note that the patch
does *not* change the feature that complex(z1, z2) returns z1 + 1j*z2 when z1 and/or
z2 is itself complex.

There was some previous discussion of this on python-dev earlier this year. See

http://mail.python.org/pipermail/python-dev/2007-January/070770.html

[gvanrossum]

Committed revision 59203.

Anthony, is this OK to backport to 2.5.2?

[mdickinson]

This is out of date for 2.5. Closing.