Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Complex number representation round-trip doesn't work with signed zero values #61538

Closed
manueljacob mannequin opened this issue Mar 2, 2013 · 6 comments
Closed

Complex number representation round-trip doesn't work with signed zero values #61538

manueljacob mannequin opened this issue Mar 2, 2013 · 6 comments
Labels
type-bug An unexpected behavior, bug, or error

Comments

@manueljacob
Copy link
Mannequin

manueljacob mannequin commented Mar 2, 2013

BPO 17336
Nosy @mdickinson, @ericvsmith, @ezio-melotti, @skrah, @manueljacob

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:

assignee = None
closed_at = <Date 2013-03-02.19:17:11.567>
created_at = <Date 2013-03-02.11:28:04.338>
labels = ['type-bug', 'invalid']
title = "Complex number representation round-trip doesn't work with signed zero values"
updated_at = <Date 2020-08-05.12:03:02.458>
user = 'https://github.com/manueljacob'

bugs.python.org fields:

activity = <Date 2020-08-05.12:03:02.458>
actor = 'Eric Wieser'
assignee = 'none'
closed = True
closed_date = <Date 2013-03-02.19:17:11.567>
closer = 'mark.dickinson'
components = []
creation = <Date 2013-03-02.11:28:04.338>
creator = 'mjacob'
dependencies = []
files = []
hgrepos = []
issue_num = 17336
keywords = []
message_count = 6.0
messages = ['183313', '183342', '183343', '374872', '374873', '374878']
nosy_count = 6.0
nosy_names = ['mark.dickinson', 'eric.smith', 'ezio.melotti', 'skrah', 'mjacob', 'Eric Wieser']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue17336'
versions = ['Python 3.3']

@manueljacob
Copy link
Mannequin Author

manueljacob mannequin commented Mar 2, 2013

When evaluating, signed zero complex numbers aren't recovered correctly.
>>> -0j
(-0-0j)
>>> (-0-0j)
0j
>>> 0j
0j

According to http://docs.python.org/dev/reference/datamodel.html#object.\_\_repr__ the representation can be used to recreate an object with the same value. Shouldn't this also be possible with complex numbers?

When using complex('...'), round-trip works correctly. While this can be used to recover the exact number, i find it confusing that complex('...') isn't the same as eval('...').
>>> complex('-0j')
-0j
>>> complex('(-0-0j)')
(-0-0j)
>>> complex('0j')
0j

@manueljacob manueljacob mannequin added the type-bug An unexpected behavior, bug, or error label Mar 2, 2013
@mdickinson
Copy link
Member

This is not easy to avoid, I'm afraid, and it's a consequence of Python's usual rules for mixed-type arithmetic: (-0-0j) is interpreted as 0 - (0.0 + 0.0j) --- that is, the 0j is promoted to a complex instance (by giving it zero real part) before the subtraction is performed. Then the real part of the result is computed as 0.0 - 0.0, which is 0.0. Note that the first 0.0 comes from converting the *integer* 0 to a complex number. If you do -0.0-0.0j you'll see a different result:

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

@mdickinson
Copy link
Member

An aside: C99 gets around this problem by allowing an (optional) Imaginary type, separate from Complex. Very few compilers support it, though.

@mdickinson
Copy link
Member

The issue of changing the complex repr came up again in bpo-41485, which has been closed as a duplicate of this issue.

See also https://bugs.python.org/issue23229#msg233963, where Guido says:

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

FWIW, I'd be +1 on changing the complex repr, but given Guido's opposition we're probably looking at a PEP to make that happen, and I don't have the bandwidth or the energy to push such a PEP through.

@mdickinson
Copy link
Member

Also related: bpo-40269

@EricWieser
Copy link
Mannequin

EricWieser mannequin commented Aug 5, 2020

BTW I don't want repr() of a complex number to use the complex(..., ...)

A compromise would be to only use this notation if signed zeros are involved.

---

Another option would be to use slightly unusual reprs for these complex numbers, which at least round-trip:

    def check(s, v):
        c = eval(s)
        # use string equality, because it's the easiest way to compare signed zeros
        cs = f"complex({c.real}, {c.imag})"
        vs = f"complex({v.real}, {v.imag})"
        assert vs == cs, f' expected {vs} got {cs}'
check("-(0+0j)", complex(-0.0, -0.0))
check("(-0.0-0j)", complex(-0.0, 0.0))  # non-intuitive
check("-(-0.0-0j)", complex(0.0, -0.0))  # non-intuitive

Which I suppose would extend to complex numbers containing just one signed zero

check("(-0.0-1j)", complex(-0.0, -1))
check("-(0.0-1j)", complex(-0.0, 1))
check("-(1+0j)", complex(-1, -0.0))
check("-(-1+0j)", complex(1, -0.0))

Only two of these reprs are misleading for users who don't understand what's going on, the rest will just strike users as odd.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

1 participant