Add cupyx.rsqrt

[kmaehashi]

This PR implements cupy.rsqrt as discussed in chainer/chainer#4092.

[beam2d]

Is it safe to add rsqrt under the cupy namespace? I'm concerning the possibility of NumPy adding numpy.rsqrt in the future with a different interface (I believe it hardly occurs because it's more natural to support it as a ufunc, but we cannot guarantee that).

[kmaehashi]

I followed the convention of how cupy.scatter_add is exposed (scatter_add is cupy-specific and placed directly under cupy namespace), but as you pointed out, rsqrt seems to have relatively higher risk of future conflict than scatter_add.
Providing it as cupy.ext.rsqrt may be better.

@unnonouno san, do you have any ideas?

[unnonouno]

I prefer cupy.ext.rsqrt and also cupy.ext.scatter_add.

[kmaehashi]

OK, I fixed to expose it as cupy.ext.rsqrt.

[niboshi]

Is it safe to bring cupy.ext into a documented API?
There may be numpy.ext in the future.

[kmaehashi]

Do you have a concern with the name ext, or (more generally) adding something under cupy namespace?

If the former is your concern, and we can't come up with any better name, we can ask "Do you have any plan to implement numpy.ext?" to numpy-discussion list. This at least notify NumPy dev team to know about us and the fact that we want to avoid future collision.

[niboshi]

My concern is both.
Especially ext is relatively likely to be added to NumPy in the future.
While of course it's best to avoid using all such identifiers that could colide with NumPy, we may ignore the odds of numpy.fusion or numpy.memoize being introduced to NumPy.
But I don't think numpy.ext is the same (maybe subjective).

I think it's difficult (or impossible) for them to answer your question.
It should be our duty to avoid using such identifiers.

[kmaehashi]

Especially ext is relatively likely to be added to NumPy in the future.

Honestly I was thinking of that but I didn't come up with the good name. How about special?

I think it's difficult (or impossible) for them to answer your question.
It should be our duty to avoid using such identifiers.

Yes, I completely agree with it. I'm also not expecting the answer or promise.
What I mean is that we can communicate with NumPy dev guys so that they (may possibly) keep a future conflict with us in their mind, not only for this case.
This is "done is better that doing nothing" approach. We have to pollute namespace anyway, and we are always responsible for it.

[beam2d]

I feel special is more likely to conflict, observing scipy has this namespace.

The cleanest solution would be creating a completely new root namespace, like cupyext (or more shortly cupyx or sth like that). Isn't it possible?

[niboshi]

I think they're good.

One concern is that cupyx reminds me of Cython extension .pyx, but maybe it's not relevant for users.

[kmaehashi]

In the weekly meeting we think it is good to have a separate package namespace (cupyx).
I'll update the PR accordingly.

[kmaehashi]

Rebased to the latest master.

[okuta]

LGTM except comment.

[okuta]

cupyx.rsqrt ?

[kmaehashi]

Jenkins, test this please.

[okuta]

jenkins, test this please.

[codecov-io]

Codecov Report

Merging #846 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #846   +/-   ##
=======================================
  Coverage   93.37%   93.37%           
=======================================
  Files         107      107           
  Lines        5807     5807           
=======================================
  Hits         5422     5422           
  Misses        385      385

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3de058a...f159f04. Read the comment docs.

[okuta]

Cloud you remove cupy/dlpack/a.out ?
And, please add rsqrt to document.

[kmaehashi]

Oh, sorry. Force-pushed.

[okuta]

LGTM!