8000 Add numpy.phase in addition to numpy.angle · Issue #3621 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Add numpy.phase in addition to numpy.angle #3621

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.

Sign up for GitHub

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

Jump to bottom
Closed
SuperFluffy opened this issue Aug 15, 2013 · 13 comments
Closed

Add numpy.phase in addition to numpy.angle #3621

SuperFluffy opened this issue Aug 15, 2013 · 13 comments
Labels
01 - Enhancement 54 - Needs decision component: documentation component: numpy._core

Comments

@SuperFluffy
Copy link

I wanted to suggest adding a function which directly gives the phase of a complex valued number instead of the angle:

def phase(z): # Calculates the phase of a complex number
  r = numpy.absolute(z)
  return (z.real/r + 1j * z.imag/r)

This is a simple enhancement, which I think would make numpy more consistent and offer the benefit of simply being faster in large loops, rather than going the ang = numpy.angle(z); phase = numpy.cos(ang) + 1j * numpy.sin(ang) route (or numpy.cos(1j * ang), for what it's worth).
@njsmith
Copy link
Member
njsmith commented Aug 15, 2013

A shorter implementation would be
z / np.abs(z)

I'm dubious that such a tiny function is worth including...
On 15 Aug 2013 13:58, "SuperFluffy" notifications@github.com wrote:

I wanted to suggest to add a function which directly gives the phase of a
complex valued number instead of the angle:

def phase(z): # Calculates the phase of a complex number
r = numpy.absolute(z)
return (z.real/r + 1j * z.imag/r)

This is a simple enhancement, which I think would make numpy more
consistent and offer the benefit of simply being faster in large loops,
rather than going the ang = numpy.angle(z); phase = numpy.cos(ang) + 1j *
numpy.sin(ang) route (or numpy.cos(1j * ang), for what it's worth).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3621
.

@charris
Copy link
Member
charris commented Aug 15, 2013

@njsmith Some folks use that as the sign function for complex, so it might be worth having.

@njsmith
Copy link
Member
njsmith commented Aug 15, 2013

I don't have a strong opinion either way, just raising the issue. Having a
plethora of confusingly similar functions should be avoided though...

what the heck does our sign function do for complex numbers? Is this like
cmp(z, 0) with lexicographic order? Is that actually useful to anyone and
could we change it to this much more sensible definition?

(numpy.linalg.slogdet is one function that uses the abs(z) == 1 definition
of sign for complex numbers.)

On Thu, Aug 15, 2013 at 2:38 PM, Charles Harris notifications@github.comwrote:

@njsmith https://github.com/njsmith Some folks use that as the signfunction for complex, so it might be worth having.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3621#issuecomment-22703179
.

@charris
Copy link
Member
charris commented Aug 15, 2013

Yep, that is what it does ;) I don't know that we can just change it, OTOH, I doubt many use the current form for complex.

@njsmith
Copy link
Member
njsmith commented Aug 15, 2013

Yeah, if my guess is right and no-one uses that, then no-one will complain
if we transition it... it'd take a few releases still to follow the
deprecation cycle but it might be best to ask people to just write 'z /
np.abs(z)' until 1.11 or whatever, rather than add a new function to the
namespace?

On Thu, Aug 15, 2013 at 9:48 PM, Charles Harris notifications@github.comwrote:

Yep, that is what it does ;) I don't know that we can just change it,
OTOH, I doubt many use the current form for complex.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3621#issuecomment-22729122
.

@pv
Copy link
Member
pv commented Aug 16, 2013

Numpy's complex sign function is sqrt(z^2)/z which is a valid analytic continuation of the real sign function, which z/|z| is not.

-1 for changing this.

@njsmith
Copy link
Member
njsmith commented Aug 16, 2013

Huh, that is interesting! Thanks.

It does look like every software package I can find uses the z/|z|
definition though, which is a bit unfortunate. (Maple has a second function
csgn that gives sqrt(z^2)/z.) Not sure if that should bother us or not.
(Though at the least our docs could be more explicit about this.)
On 16 Aug 2013 10:40, "Pauli Virtanen" notifications@github.com wrote:

Numpy's complex sign function is sqrt(z^2)/z which is a valid analytic
continuation of the real sign function.
(It's analytic, and hence better than z/|z|)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3621#issuecomment-22756924
.

@pv
Copy link
Member
pv commented Aug 16, 2013

Yes, numpy seems to be pretty much alone in defining sign for complex-valued numbers like this. (Ok, not alone if you count mathematical literature.)

However, because the behavior is still sort of sensible, I'd be somewhat wary of changing it, as it is not clear that it won't break things.

The documentation should be changed to mention the exact definition used in any case, though.

@charris
Copy link
Member
charris commented Feb 23, 2014

How about adding a sgn function?

Documentation of sign should definitely mention it's defininition.

@lebigot
Copy link
Contributor
lebigot commented Apr 21, 2015

Side note: an argument against calling such a function phase is that cmath.phase() does something different (it essentially returns the same thing as numpy.angle().

@eric-wieser
Copy link
Member

On a similar note, an implementation of copysign for complex numbers would be nice, presumably with semantics abs(a) * sgn(b) - here it's pretty clear the z / |z| definition is more useful.

@mhvk
Copy link
Contributor
mhvk commented Dec 12, 2017

Second the idea of extending copysign to complex numbers (although copydirection might be more intuitive -- and extendable to vectors).

@mhvk mhvk mentioned this issue Mar 22, 2019
Open
4 tasks
@mhvk
Copy link
Contributor
mhvk commented Mar 22, 2019

I'm closing this in favour of #13179 (mostly since the title no longer reflects the discussion, and because I think the request makes more sense as part of a larger effort to make working with complex numbers a little easier).

@mhvk mhvk closed this as completed Mar 22, 2019
@mmuckley mmuckley mentioned this issue Apr 13, 2020
Closed
@mhvk mhvk mentioned this issue Jun 26, 2021
Closed
@kgryte kgryte mentioned this issue Dec 1, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
01 - Enhancement 54 - Needs decision component: documentation component: numpy._core
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@lebigot @pv @charris @eric-wieser @njsmith @SuperFluffy @mattip @mhvk
0