Error in representation of complex numbers(again)

[quiver]

BPO	1118729
Nosy	@loewis, @birkenfeld
Files	complex.diff

^{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 = 'https://github.com/loewis'
closed_at = <Date 2005-09-16.06:43:11.000>
created_at = <Date 2005-02-08.16:26:15.000>
labels = ['interpreter-core']
title = 'Error in representation of complex numbers(again)'
updated_at = <Date 2005-09-16.06:43:11.000>
user = 'https://bugs.python.org/quiver'

bugs.python.org fields:

activity = <Date 2005-09-16.06:43:11.000>
actor = 'georg.brandl'
assignee = 'loewis'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2005-02-08.16:26:15.000>
creator = 'quiver'
dependencies = []
files = ['1591']
hgrepos = []
issue_num = 1118729
keywords = []
message_count = 8.0
messages = ['24193', '24194', '24195', '24196', '24197', '24198', '24199', '24200']
nosy_count = 4.0
nosy_names = ['loewis', 'georg.brandl', 'quiver', 'sonderblade']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1118729'
versions = ['Python 2.4']

[quiver]

>>> -(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.

[sonderblade]

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.

[quiver]

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 bpo-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.

[quiver]

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

[loewis]

Logged In: YES
user_id=21627

What do you think about the patch attached?

[quiver]

Logged In: YES
user_id=671362

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

Please apply it.

[quiver]

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.

[birkenfeld]

Logged In: YES
user_id=1188172

Reviewed and applied in Objects/complexobject.c r2.74, 2.72.2.2.