[issue22548] Bogus parsing of negative zeros in complex literals

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests:  -18927

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +serhiy.storchaka
nosy_count: 3.0 -> 4.0
pull_requests: +18927
pull_request: https://github.com/python/cpython/pull/19593

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Mark Dickinson]

Mark Dickinson added the comment:

> It doesn't cover the "sum with like signs"

Ah, sorry, yes it does;  it's in the previous paragraph.

"""
[...] the sign of a sum, or of a difference x−y regarded as a sum x+(−y), 
differs from at most one of the addends’ signs
"""

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Mark Dickinson]

Mark Dickinson added the comment:

> Oops, I get it now.

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:

"""
When the sum of two operands with opposite signs (or the difference of two 
operands with like signs) is exactly zero, the sign of that sum (or difference) 
shall be +0 in all rounding-direction attributes except roundTowardNegative; 
under that attribute, the sign of an exact zero sum (or difference) shall be 
−0. However, x + x = x − (−x) retains the same sign as x even when x is zero.
"""

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Antoine Pitrou]

Antoine Pitrou added the comment:

Yes, the last part is ok. It's the preceding parts that are a bit surprising.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Antoine Pitrou]

Antoine Pitrou added the comment:

Oops, I get it now. Sorry.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Mark Dickinson]

Mark Dickinson added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Antoine Pitrou]

Antoine Pitrou added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Mark Dickinson]

Mark Dickinson added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Mark Dickinson]

Mark Dickinson added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Mark Dickinson]

Mark Dickinson added the comment:

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 `complex(real_part, imag_part)` construction.

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.

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22548] Bogus parsing of negative zeros in complex literals

[Antoine Pitrou]

New submission from Antoine Pitrou:

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

--
components: Interpreter Core
messages: 228343
nosy: benjamin.peterson, mark.dickinson, pitrou
priority: low
severity: normal
status: open
title: Bogus parsing of negative zeros in complex literals
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com