classification
Title: complex constructor loses signs of zeros
Type: Stage:
Components: Versions: Python 2.5
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: anthonybaxter Nosy List: anthonybaxter, gvanrossum, mark.dickinson
Priority: high Keywords:

Created on 2007-11-27 22:25 by mark.dickinson, last changed 2009-02-11 14:02 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
complex_new.patch mark.dickinson, 2007-11-27 22:25
Messages (3)
msg57891 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2007-11-27 22:25
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
msg57893 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-11-27 22:39
Committed revision 59203.

Anthony, is this OK to backport to 2.5.2?
msg81643 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-02-11 14:02
This is out of date for 2.5.  Closing.
History
Date User Action Args
2009-02-11 14:02:34mark.dickinsonsetstatus: open -> closed
messages: + msg81643
2008-01-28 19:39:30christian.heimessetpriority: high
versions: - Python 2.6
2007-11-27 22:39:15gvanrossumsetassignee: anthonybaxter
resolution: accepted
messages: + msg57893
nosy: + anthonybaxter, gvanrossum
2007-11-27 22:25:12mark.dickinsoncreate