Inconsistent complex behavior with (-1j)

[18a4245c-2b8d-42c7-a56d-cde27f80def3]

BPO	40269
Nosy	@tim-one, @rhettinger, @terryjreedy, @mdickinson, @stevendaprano, @serhiy-storchaka, @MojoVampire, @PistachioCake
PRs	python/cpython#19498 python/cpython#19593
Superseder	bpo-17336: Complex number representation round-trip doesn't work with signed zero values

^{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: ```python assignee = None closed_at = created_at = labels = ['type-feature', '3.8', 'docs'] title = 'Inconsistent complex behavior with (-1j)' updated_at = user = 'https://github.com/PistachioCake' ``` bugs.python.org fields: ```python activity = actor = 'mark.dickinson' assignee = 'docs@python' closed = True closed_date = closer = 'mark.dickinson' components = ['Documentation'] creation = creator = 'rushilu' dependencies = [] files = [] hgrepos = [] issue_num = 40269 keywords = ['patch'] message_count = 15.0 messages = ['366276', '366278', '366280', '366283', '366287', '366289', '366293', '366294', '366298', '366733', '366764', '366773', '367553', '367721', '374874'] nosy_count = 9.0 nosy_names = ['tim.peters', 'rhettinger', 'terry.reedy', 'mark.dickinson', 'steven.daprano', 'docs@python', 'serhiy.storchaka', 'josh.r', 'rushilu'] pr_nums = ['19498', '19593'] priority = 'normal' resolution = 'duplicate' stage = 'resolved' status = 'closed' superseder = '17336' type = 'enhancement' url = 'https://bugs.python.org/issue40269' versions = ['Python 3.8'] ```

[18a4245c-2b8d-42c7-a56d-cde27f80def3]

In a Python REPL:

>>> -1j
(-0-1j)
>>> (-1j)
(-0-1j)
>>> 0-1j
-1j
>>> -0-1j
-1j

This is clearly inconsistent behavior! -1j and (-1j) should report as -1j, as the other two do.

[99ffcaa5-b43b-4e8e-a35e-9c890007b9cd]

The final entry is identical to the second to last, because ints have no concept of -0. If you used a float literal, it would match the first two:

>>> -0.-1j
(-0-1j)

I suspect the behavior here is due to -1j not actually being a literal on its own; it's interpreted as the negation of 1j, where 1j is actually 0.0+1.0j, and negating it flips the sign on both the real and imaginary component.

From what I can read of the grammar rules, this is expected; the negation isn't ever part of the literal (minus signs aren't part of the grammar aside from exponents in scientific notation). https://docs.python.org/3/reference/lexical_analysis.html#floating-point-literals

If this is a bug, it's a bug in the grammar. I suspect the correct solution here is to include the real part explicitly, as 0.0-1j works just fine.

[rhettinger]

The docs for complex literals¹ could be improved to show that:

-1j is interpreted as -complex(0.0, 1.0)
giving a real component of -0.0
and an imaginary component of -1.0

and that:

0-1j is interpreted as 0.0-complex(0.0, 1.0) giving a real component of 0.0 and an imaginary component of -1.0

It is unfortunate the repr for complex numbers uses integers at all. That hides what is going on.

¹ https://docs.python.org/3/reference/lexical_analysis.html#imaginary-literals

[stevendaprano]

Would we be willing to consider an enhancement to have complex numbers always display using float format rather than ints?

1+1j --> 1.0+1.0j

We could still suppress an unsigned real zero:

1j --> 1.0j

but negative zero would show:

-(1j) --> -0.0-1.0j

I daresay this would break some doctests (CC'ing Tim, as he is a heavy user of doctests) but perhaps it would be worthwhile.

Aside from the backwards-compatibility issue, going against this suggestion we have the popular Texas Instruments Nspire calculator, which shows complex numbers as ints when possible.

On the other hand, the imaginary unit is shown as the symbolic constant i with no coefficient, and it also shows complex numbers with an explicit multiplication sign: 2⋅i rather than 2i.

Similarly, Julia shows complex numbers with integer coefficients when possible:

https://docs.julialang.org/en/v1/manual/complex-and-rational-numbers/

[serhiy-storchaka]

It is a known issue, but I have no references to previous discussions. Outputting numbers with decimal point will not help in case of complex(-0.0, 1.0). Maybe the only way to solve this problem is to implement special Imaginary type (as a subclass of complex).

[mdickinson]

See also bpo-25839, bpo-22548; there's lot of discussion of the core issue on those tickets. As Serhiy says, the only reasonable "true" fix would be to have 1j be a genuine imaginary literal, but that's a lot of work and potential disruption (not just to core Python, but to 3rd party libraries that care about complex numbers) for not a lot of gain.

A documentation improvement as suggested by Raymond sounds good.

I'm not keen on messing with the complex __repr_ again, but if we did, I'd propose not only representing real and imaginary parts in a way that's consistent with floats (so with both real and imaginary parts having either decimal points or exponents), but also showing _both the real and imaginary parts in all complex numbers. That is:

    >>> 1j
    0.0 + 1.0j

Or if we're willing to accept more backwards compatibility breakage, there's a case for having the __repr (but not the __str) of a complex number take the form

    >>> 1j
    complex(0.0, 1.0)

since this the only way that allows easy round-tripping. Otherwise you still have this problem:

    >>> complex(-0.0, 1.0)
    (-0+1j)
    >>> -0 + 1j
    1j

BTW, I still dislike the parentheses around the current complex repr.

Let's keep this issue open for potential documentation improvements. If we want to change the repr of complex, let's open another issue for that.

[serhiy-storchaka]

The Imaginary type could help to solve other "gotchas". For example, in Python

>>> complex(0, float('inf')) * 1
(nan+infj)

But in C++ you will get the real component 0, because multiplication of complex and real numbers is component wise.

With the Imaginary type we could get that 1j * x == complex(0, x) for all float x, including infinity and NaN.

Returning to the repr, the other way to correctly represent the repr of complex(-0.0, 1.0) is writing it as "-(0.0-1j)", but it looks unnatural to me.

[mdickinson]

The Imaginary type could help to solve other "gotchas".

Yes, it's an attractive proposition from many angles: e.g., multiplying by 1j could do the correct quarter-turn rotation in the complex plane, keeping all signs correct, so that multiplying a complex number z by 1j 4 times exactly recovers z, regardless of nans, infinities and signed zeros.

C99's specification of (optional) imaginary types was supposed to solve exactly this problem, but it doesn't look as though it received widespread adoption, and I suspect it would have difficulty getting traction in Python world, too.

I'll have a PR with a documentation update shortly.

[mdickinson]

Another related issue is bpo-23229, where Guido says (in msg233963):

BTW I don't want repr() of a complex number to use the complex(..., ...) notation -- it's too verbose.

[rhettinger]

Since integers don't have signed zeros, the use of integers in the complex repr is a little weird:

>>> (-0-1j)         # The unary minus in the repr has no effect.
-1j
>>> (0-1j)
-1j

[serhiy-storchaka]

I tried to make repr of floats producing a string which rounds up with eval() (see PR 19593).

>>> complex(0.0, 1.0)
1j
>>> complex(0.0, -1.0)
(0-1j)
>>> complex(-0.0, 1.0)
-(0-1j)
>>> complex(-0.0, -1.0)
(-0.0-1j)
>>> complex(1.0, 0.0)
(1+0j)
>>> complex(-1.0, 0.0)
(-1+0j)
>>> complex(1.0, -0.0)
-(-1+0j)
>>> complex(-1.0, -0.0)
-(1+0j)

The largest problem is with complex(-0.0, 0.0) and complex(-0.0, 0.0). The only forms which evaluate to these numbers are:

>>> complex(-0.0, 0.0)
(-0.0-0j)
>>> complex(0.0, -0.0)
-(-0.0-0j)

But it conflicts with the constructor:

>>> complex('(-0.0-0j)')
-(0+0j)

[mdickinson]

I tried to make repr of floats producing a string which rounds up with eval()

We've looked at this before. There just isn't any sane and easy way to do this, except for changing the repr to be "complex(real, imag)", which is the solution that I favour.

And this seems like a non-starter to me:

    >>> complex(0.0, -0.0)
    -(-0.0-0j)

This is a case where the cure is worse than the disease.

We should also not change the repr lightly: the last time it was changed, it caused disruption at least for Cython, and probably for NumPy too. As a corollary, if we _do_ change it, we should make sure we get it right so that we're changing it to something we're not going to want to change again in 5 years' time. And I suspect that if we don't solve the underlying roundtrip problem, then this is going to come up again.

I'm +1 on changing the repr to "complex(..., ...)", +0 on modifying it to always include both real and imaginary parts _and_ format those parts as though they're floats; -1 on other changes.

[mdickinson]

Closing this. Please open a separate issue for changing the complex repr if that's the way that you want to go.

[terryjreedy]

After reading through the comments, I don't think we should change repr(complex) unless there is computational issue, such as eval(repr(z) != z. Raymond, I agree with your overlooked doc tweek. If you submit a PR, you can ask me to review.

[mdickinson]

Updating resolution to "duplicate", in an effort to keep discussion in a single place.