Behavior of np.sign for complex number (Trac #1250)

[numpy-gitbot]

Original ticket http://projects.scipy.org/numpy/ticket/1250 on 2009-10-06 by atmention:huard, assigned to atmention:pv.

For complex arguments, np.sign returns the following:

> [10]: np.sign(1j)
 <[10]: (1+0j)

> [11]: np.sign(-1j)
 <[11]: (-1+0j)

> [12]: np.sign(1-1j)
 <[12]: (1+0j)

So the sign of the real part takes precedence on the sign of the complex part when there is a real part. I'm not sure if this qualifies as a bug, but it's not intuitive, nor documented.

[numpy-gitbot]

atmention:charris wrote on 2009-10-06

It is just comparing the complex number to zero, the odd behaviour is due to the lexicographic sort order adopted for complex numbers. The sign of a complex number really doesn't have any natural definition.

[numpy-gitbot]

atmention:cournape wrote on 2009-10-08

Should we raise an exception in that case ?

[numpy-gitbot]

trac user madhusudancs wrote on 2009-12-27

I think this behaviour is correct. From what I remember from my school days study of complex numbers, what NumPy returns is exactly what it should return. I don't have a reference to an authentic source, but Wikipedia provides a similar definition too: http://en.wikipedia.org/wiki/Negative_and_non-negative_numbers#Signum_function

I am referring to csgn(x) function here.

[numpy-gitbot]

atmention:huard wrote on 2010-01-04

Thanks for the feedback, I'll work on the docs then.

[numpy-gitbot]

atmention:mwiebe wrote on 2011-03-24

I think it should raise an exception, since the sign of a complex number isn't well-defined.

[numpy-gitbot]

Milestone changed to Unscheduled by atmention:mwiebe on 2011-03-24

[numpy-gitbot]

atmention:pv wrote on 2011-03-25

There are basically two common complex sign functions: z/sqrt(z^2) -- which is what sign() currently does, and z/|z| -- which e.g. Mathematica uses. I've seen both used in the literature.

I don't think there is a big need for it to raise an exception, as there is not that much room for confusion, and I don't see this as a big source of bugs. Just explaining the current behavior in the docstring should be enough.