repr(complex) in Py3.1

[Stefan Behnel]

Hi,

in Python 3.1.1, I get this:

Python 3.1.1 (r311:74480, Oct 22 2009, 19:34:26)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information. (-0-2j)

The last line differs from what earlier Python versions printed here:

Python 2.6.2 (r262:71600, Oct 22 2009, 20:58:58)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information. -2j

I know at least that the float repr() was modified in Py3.1, but is the
above behaviour intentional? It certainly breaks doctests, and I don't see
a good reason for that.

Stefan

 

[Mark Dickinson]

Hi,

in Python 3.1.1, I get this:

  Python 3.1.1 (r311:74480, Oct 22 2009, 19:34:26)
  [GCC 4.3.2] on linux2
  Type "help", "copyright", "credits" or "license" for more information..
  >>> 2j
  2j
  >>> -2j
  -2j
  >>> -0-2j
  -2j
  >>> (-0-2j)
  -2j
  >>> -(2j)
  (-0-2j)

The last line differs from what earlier Python versions printed here: [...]
I know at least that the float repr() was modified in Py3.1, but is the
above behaviour intentional? It certainly breaks doctests, and I don't see
a good reason for that.

Yes, it's intentional. The problem with the 2.6 complex repr is that
it doesn't accurately represent negative zeros, so that if you try
to eval the result you don't end up with the same complex number:

Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.0.0

This was part of a set of changes made to ensure that complex(repr(z))
round-tripping worked correctly, even when z involves negative zeros,
nans, or infinities. (However, note that eval(repr(z)) doesn't
round-trip correctly; that's not a problem that's easy to solve.)

Mark

 

[Martin v. Löwis]

I know at least that the float repr() was modified in Py3.1, but is the

above behaviour intentional? It certainly breaks doctests, and I don't see
a good reason for that.

I don't know whether it was intentional, but it looks right to me.
2j is the complex number +0.0+2.0j (right?). Then, -(2j) is the negated
value of this, i.e. -0.0-2.0j (*). It seems that the complex type made
no distinction between +0.0 and -0.0 in the past, but it should (just as
the float type does).

Regards,
Martin

(*) this is different from -2j, where the sign applies to the imaginary
part only.

 

[Stefan Behnel]

Mark Dickinson, 24.10.2009 16:44:

in Python 3.1.1, I get this:

Python 3.1.1 (r311:74480, Oct 22 2009, 19:34:26)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.

-(2j)

(-0-2j)

The last line differs from what earlier Python versions printed here.
I know at least that the float repr() was modified in Py3.1, but is the
above behaviour intentional? It certainly breaks doctests, and I don't see
a good reason for that.

Yes, it's intentional. The problem with the 2.6 complex repr is that
it doesn't accurately represent negative zeros, so that if you try
to eval the result you don't end up with the same complex number

Ok, thanks. I guess we'll have to work around that in Cython's doctest
suite then.

Stefan