New submission from Mark Dickinson: 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 ---------- files: complex_new.patch messages: 57891 nosy: marketdickinson severity: normal status: open title: complex constructor loses signs of zeros versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file8815/complex_new.patch __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1507> __________________________________

Index: Objects/complexobject.c =================================================================== --- Objects/complexobject.c (revision 59202) +++ Objects/complexobject.c (working copy) @@ -897,6 +897,8 @@ PyNumberMethods *nbr, *nbi = NULL; Py_complex cr, ci; int own_r = 0; + int cr_is_complex = 0; + int ci_is_complex = 0; static PyObject *complexstr; static char *kwlist[] = {"real", "imag", 0}; @@ -977,6 +979,7 @@ retaining its real & imag parts here, and the return value is (properly) of the builtin complex type. */ cr = ((PyComplexObject*)r)->cval; + cr_is_complex = 1; if (own_r) { Py_DECREF(r); } @@ -985,7 +988,6 @@ /* The "real" part really is entirely real, and contributes nothing in the imaginary direction. Just treat it as a double. */ - cr.imag = 0.0; tmp = PyNumber_Float(r); if (own_r) { /* r was a newly created complex number, rather @@ -1005,15 +1007,14 @@ } if (i == NULL) { ci.real = 0.0; - ci.imag = 0.0; } - else if (PyComplex_Check(i)) + else if (PyComplex_Check(i)) { ci = ((PyComplexObject*)i)->cval; - else { + ci_is_complex = 1; + } else { /* The "imag" part really is entirely imaginary, and contributes nothing in the real direction. Just treat it as a double. */ - ci.imag = 0.0; tmp = (*nbi->nb_float)(i); if (tmp == NULL) return NULL; @@ -1021,11 +1022,16 @@ Py_DECREF(tmp); } /* If the input was in canonical form, then the "real" and "imag" - parts are real numbers, so that ci.real and cr.imag are zero. + parts are real numbers, so that ci.imag and cr.imag are zero. We need this correction in case they were not real numbers. */ - cr.real -= ci.imag; - cr.imag += ci.real; - return complex_subtype_from_c_complex(type, cr); + + if (ci_is_complex) { + cr.real -= ci.imag; + } + if (cr_is_complex) { + ci.real += cr.imag; + } + return complex_subtype_from_doubles(type, cr.real, ci.real); } PyDoc_STRVAR(complex_doc, Index: Lib/test/test_complex.py =================================================================== --- Lib/test/test_complex.py (revision 59202) +++ Lib/test/test_complex.py (working copy) @@ -9,6 +9,7 @@ ) from random import random +from math import atan2 # These tests ensure that complex math does the right thing @@ -225,6 +226,18 @@ self.assertAlmostEqual(complex(real=17+23j, imag=23), 17+46j) self.assertAlmostEqual(complex(real=1+2j, imag=3+4j), -3+5j) + # check that the sign of a zero in the real or imaginary part + # is preserved when constructing from two floats. (These checks + # are harmless on systems without support for signed zeros.) + def split_zeros(x): + """Function that produces different results for 0. and -0.""" + return atan2(x, -1.) + + self.assertEqual(split_zeros(complex(1., 0.).imag), split_zeros(0.)) + self.assertEqual(split_zeros(complex(1., -0.).imag), split_zeros(-0.)) + self.assertEqual(split_zeros(complex(0., 1.).real), split_zeros(0.)) + self.assertEqual(split_zeros(complex(-0., 1.).real), split_zeros(-0.)) + c = 3.14 + 1j self.assert_(complex(c) is c) del c

_______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com