Skip to content
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

[Tracker] Implement all numpy.* APIs in CuPy #6078

Open
26 of 68 tasks
kmaehashi opened this issue Nov 11, 2021 · 19 comments
Open
26 of 68 tasks

[Tracker] Implement all numpy.* APIs in CuPy #6078

kmaehashi opened this issue Nov 11, 2021 · 19 comments

Comments

@kmaehashi
Copy link
Member

kmaehashi commented Nov 11, 2021

Implement GPU version of numpy.* functions in cupy.* namespace.

This is a tracker issue that lists the remaining numpy.* APIs (see also: comparison table). I've categorized them based on difficulty so that new contributors can pick the right task. Your contribution is highly welcomed and appreciated!

List of APIs

Very Easy

Easy

Medium

Medium to Hard

Low priority (iterator functions)

Low priority (help functions)

Low priority (internal functions)

Low priority (dtype APIs - need to filter types unsupported by CuPy)

Low priority (rarely used APIs)

Steps to Contribute

  1. Fork and star ⭐ the CuPy repository 😉

  2. Pick a function you want to work on. You can find the function in the NumPy API Reference to understand what should be implemented.

  3. Implement a function in your branch. If you need help, join Gitter or just ask for help in this issue.

  4. Don't forget to write a test code!

  5. Build CuPy and run tests to confirm that the function runs fine:
    pip install -e . && pytest tests/cupy_tests/PATH_TO_YOUR_TEST
    See the Contribution Guide for details.

  6. Submit a pull-request to the main branch.

Note that you will need a GPU environment to develop CuPy.

See also:

@khushi-411
Copy link
Contributor

Hi @kmaehashi,
I am glad to look into the awesome collection of required APIs.

I was wondering if other APIs for constant functions like numpy.inf, numpy.ninf etc can also be added to the cupy library. Curious to know your viewpoints. Thanks!

NumPy Reference: https://numpy.org/devdocs/reference/constants.html.

@kmaehashi
Copy link
Member Author

@khushi-411 Thanks for pull-requests! All constants are imported in CuPy 😄
https://github.com/cupy/cupy/blob/v10.0.0rc1/cupy/__init__.py#L56-L73

@jakirkham
Copy link
Member

cc @leofang @grlee77 @rgommers

@rgommers
Copy link
Contributor

There's a whole bunch of very questionable stuff here, including things that are deprecated. It does not make sense to me to add those. But rather than spend time arguing about that, let me just go work on a PR to remove them from NumPy:)

@jakirkham
Copy link
Member

Yeah some of the easy and very easy things read that way to me

The medium & medium to hard seem ok though (with the exception of the typing stuff)

The iterating functions (particularly on GPUs) I'm not sure about, but maybe Leo has thoughts there.

Anything else stick out to you, Ralf? Does the above sound roughly correct to you or are there other things that stick out?

@leofang
Copy link
Member

leofang commented Nov 19, 2021

@rgommers Could you list what is deprecated/inappropriate? I thought @kmaehashi has avoided listing them.

@rgommers
Copy link
Contributor

loads and ndfromtxt were already removed in numpy/numpy#19615, so can be removed from the list.

The medium & medium to hard seem ok though (with the exception of the typing stuff)

With "typing stuff" do you mean the dtype-related functions (cast, typecodes, etc.)? If so, then I agree - that's questionable. Also xref numpy/numpy#17325 for that.

The iterating functions (particularly on GPUs) I'm not sure about, but maybe Leo has thoughts there.

Anything else stick out to you, Ralf? Does the above sound roughly correct to you or are there other things that stick out?

That sounds about right. The random and linalg stuff is important, as are some of the medium-hard functions like put_along_axis, nanquantile, nanpercentile, etc.

All of the undocumented ones I'd like to get rid of in NumPy.

@jakirkham
Copy link
Member

The medium & medium to hard seem ok though (with the exception of the typing stuff)

With "typing stuff" do you mean the dtype-related functions (cast, typecodes, etc.)? If so, then I agree - that's questionable. Also xref numpy/numpy#17325 for that.

Yeah exactly. Sorry that was vague

@rgommers
Copy link
Contributor

alen and asscalar will be removed in 1.23.0 (probably, unless it still gets backported to 1.22.x) by numpy/numpy#20414

@rgommers
Copy link
Contributor

@kmaehashi
Copy link
Member Author

@rgommers Thank you for all the information. I've removed deprecated ones from the list:

  • numpy.loads
  • numpy.ndfromtxt
  • numpy.alen
  • numpy.asscalar
  • numpy.ndarray.tostring
  • numpy.set_numeric_ops

Also marked dtype-related functions as low priority as there's an ongoing discussion in NumPy.

@knshkp
Copy link

knshkp commented Mar 16, 2022

i also want to contribute in this library but when i seen this all issues are resolved so could you please assign me a tasks

This was referenced Mar 23, 2022
tom24d added a commit to tom24d/cupy that referenced this issue Jun 22, 2022
Reference: cupy#6078
tom24d added a commit to tom24d/cupy that referenced this issue Jun 22, 2022
Reference: cupy#6078
tom24d added a commit to tom24d/cupy that referenced this issue Jun 22, 2022
@Nordicus
Copy link
Contributor

Nordicus commented Nov 9, 2022

I've noticed that the automatic domain functions (numpy.emath.* or numpy.lib.scimath.*) seem to be missing from this. Is this a mistake, or are they not supposed to be supported?
https://numpy.org/doc/stable/reference/routines.emath.html

@kmaehashi
Copy link
Member Author

@Nordicus Yes it's just because I overlooked it, thanks for the catch! 😄

@pri1311
Copy link
Contributor

pri1311 commented Nov 24, 2022

Hi team, I was looking into implementing cupy.emath.* and I believe the implementation is pretty simple. And since all our functions sqrt, log, etc are implemented using ufunc and already support complex numbers it is just a matter of converting any negatives into complex numbers like in numpy with no other changes required. Is my thinking correct? Pardon my negligence if any.

@kmaehashi
Copy link
Member Author

@pri1311 Hi, I agree it should be that simple.

@rajveer43
Copy link

hey @kmaehashi , I would like to work on numpy.ndarray.resize

@kmaehashi
Copy link
Member Author

Hi @rajveer43, sure go ahead.

@rajveer43
Copy link

Hi @rajveer43, sure go ahead.

I know how to add that function but..can you tell the locations i.e. path..where it is needed to be added? I am getting confused actually!

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

9 participants