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
