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
Bogus parsing of negative zeros in complex literals #66738
Comments
This may be a parser limitation... >>> z = -0.-0.j
>>> z
(-0+0j)
>>> z.imag
0.0
>>> z = 0.-0.j
>>> z.imag
0.0 |
This is not a bug, but a known and difficult-to-avoid issue with signed zeros and creating complex numbers from real and imaginary parts. The safe way to do it is to use the In the first example, you're subtracting a complex number (0.j) from a float (-0.0). The float gets promoted to a complex (by filling in an imaginary part of +0.0), and the imaginary literal is similarly treated as a complex number (by filling in a 0.0 for the real part). So the subtraction is doing: complex(-0.0, 0.0) - complex(0.0, -0.0) which as expected gives a real part of -0.0, and an imaginary part of +0.0. |
Sorry; that should be: complex(-0.0, 0.0) - complex(0.0, 0.0) The imaginary part is then worked out as (0.0 - 0.0), which (in all rounding modes but round-towards-negative) is 0.0. |
P.S. The C standardisation folks tried to introduce the Imaginary type (optional for a conforming implementation) to get around exactly this type of problem, but it doesn't seem to have caught on in most mainstream compilers. |
FTR, a similar issue with regular floats: >>> -0.0-0.0
-0.0
>>> (-0.0)-0.0
-0.0
>>> z = -0.0
>>> z - z
0.0 |
Nope, no float issue here. :-) Which part of the output do you think is wrong? Your last (z - z) is doing ((-0.0) - (-0.0)), not (-0.0 - 0.0). This is all following the IEEE 754 rules. |
Yes, the last part is ok. It's the preceding parts that are a bit surprising. |
Oops, I get it now. Sorry. |
Okay. :-) Just for the record, for anyone encountering this issue in the future, here's the relevant extract from section 6.3 of IEEE 754-2008: """ It doesn't cover the "sum with like signs" or "difference with opposite signs" cases, I suppose because it should be obvious what happens in those cases. |
Ah, sorry, yes it does; it's in the previous paragraph. """ |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: