This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Error in representation of complex numbers(again)
Type: Stage:
Components: Interpreter Core Versions: Python 2.4
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: loewis Nosy List: georg.brandl, loewis, quiver, sonderblade
Priority: normal Keywords:

Created on 2005-02-08 16:26 by quiver, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
complex.diff loewis, 2005-05-15 07:57
Messages (8)
msg24193 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2005-02-08 16:26
>>> -(1+0j)
(-1+-0j)

I encountered this while I was calculating conjugate of 
complex numbers(e.g. z.conjugate()).

Related bug
* http://www.python.org/sf/1013908

One thing to note is that -(0j) can return 0j or -0j 
dependeing on OSes.

Confirmed on SuSE 9.1 & cygwin.
msg24194 - (view) Author: Björn Lindqvist (sonderblade) Date: 2005-02-09 18:54
Logged In: YES 
user_id=51702

What you are seeing is negative zero (-0.0). It is distinct 
from positive zero (0.0) but 0.0 == -0.0 is always true. On 
some machines you can also see it by typing:

>>> -0.0
-0.0

On other machines you will see "0.0" instead. You can also try 
printf("%f\n", -0.0); and you will notice the same thing. So 
I'm not sure it is a bug per se. However, it can be worked 
around by adding "if (v->cval.imag == 0.) v->cval.imag = 
0.0;" to complexobject.c, assuming ofcourse it is OK to 
change negative zeros to positive ones.
msg24195 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2005-02-10 00:02
Logged In: YES 
user_id=671362

Hi, Björn.

Sorry, not to be clear about what my complaint is.  I'm not 
talking about if -(0j) should be 0j or -0j.  It's been that way 
for a long time, so changing it would break old codes.

My point is the signature of imaginary part. As you can see, 
it's represented as '+-'. Before the commit of patch #774665, 
it was represented as '-1-0j'. But after that, '-1+-0j'.

If you test it with Python <= 2.3, you'll get (-1-0j) and I think 
this is how -(1+0j) should be represented on machines where -
(0j) is represented as -0j.
msg24196 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2005-03-19 17:11
Logged In: YES 
user_id=671362

Martin, what's your take on this?

The representation of '-(1+0j)' has changed since Revision 2.71
(complexobject.c) and you applied the patch.

# original patch
making Python LC_NUMERIC agnostic
  http://www.python.org/sf/774665
msg24197 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-05-15 07:57
Logged In: YES 
user_id=21627

What do you think about the patch attached?
msg24198 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2005-05-15 12:22
Logged In: YES 
user_id=671362

The fix seems reasonable to me and it passed the test 
suites. 

Please apply it.
msg24199 - (view) Author: George Yoshida (quiver) (Python committer) Date: 2005-09-16 05:02
Logged In: YES 
user_id=671362

Can anyone else review this patch before the new 2.4 gets 
released?
The patch is ready to be commited.
msg24200 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2005-09-16 06:43
Logged In: YES 
user_id=1188172

Reviewed and applied in Objects/complexobject.c r2.74, 2.72.2.2.
History
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41547
2005-02-08 16:26:15quivercreate