8000 Ufuncs for complex numbers · Issue #13179 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

Ufuncs for complex numbers #13179

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.

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

Open
1 of 4 tasks
mhvk opened this issue Mar 22, 2019 · 8 comments
Open
1 of 4 tasks

Ufuncs for complex numbers #13179

mhvk opened this issue Mar 22, 2019 · 8 comments

Comments

@mhvk
Copy link
Contributor
mhvk commented Mar 22, 2019

This is a tracker for a number of requests for making working with complex numbers a bit easier/faster

EDIT (2021-Jun-25): if there is worry about making the numpy API too big, one option might be to make this part of numpy.lib.scimath (which I must admit I didn't know about until today; I see now that it should be np.emath - https://numpy.org/devdocs/reference/routines.emath.html). Though perhaps that should stay reserved for complex continuations real->complex like for sqrt.

@rkern
Copy link
Member
rkern commented Jun 26, 2021

numpy.emath isn't the right place for these. That module is really just for functions which have useful RR->RR variants that are the main versions in the numpy namespace (e.g. where np.sqrt(-1) raises an exception) but where we also want a variant that treats the whole RR number line as a subset of the complex numbers CC (e.g. where np.sqrt(-1) == 1j).

scipy.special is the default place where new ufuncs like these should start out.

@NeilGirdhar
Copy link
Contributor

@rkern Makes sense. What do you think about making an issue like this in the scipy repository?

@mhvk
Copy link
Contributor Author
mhvk commented Jun 26, 2021

@rkern - sticking to the usual consideration that numpy should just cover the standard C math library, I guess these complex ufuncs indeed do not quite belong in numpy, though especially for expj, where one could use the sincos built-in, @charris and @juliantaylor were more on the fence (see #5625). Also, the functions requested here would seem a bit odd amidst the bessell functions etc in scipy.special, even though it has a section with convenience functions *which includes cbrt that later moved to numpy).

Looking a bit further afield, base math for julia includes abs2 and uses z/|z| for sign, which is more useful than the strange one used for np.sign - see #3621. And in python cmath.rect and cmath.polar transform to/from complex real/imag and polar representations.

@rkern
Copy link
Member
rkern commented Jun 26, 2021

I'm not necessarily opposed to some of these making their way into numpy's namespace. But scipy.special is going to be where you will face the least resistance to a PR offering these. They do fit within scipy.special's scope.

@charris
Copy link
Member
charris commented Jun 26, 2021

TBH, I've often thought an abs2 would be useful, I've probably needed it as often as abs. The definition of sign or sgn might usefully be addressed in the proposed API document.

@mhvk
Copy link
Contributor Author
mhvk commented Jun 26, 2021
8000

abs2 definitely has come up most often as a request; much use of FFTs at some point involves the power spectrum (aside, @NeilGirdhar, this is why I had it as power above before you asked me to change it to the (better) square modulus...). expj is particularly helpful also in Fourier analysis, for unequally spaced data. But I may have been looking at radio baseband data too much!

@mhvk
Copy link
Contributor Author
mhvk commented Jun 26, 2021

@charris - what is "the proposed API document"?

@charris
Copy link
Member
charris commented Jun 26, 2021

@mhvk The array api standard, see #18585.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants
0