ENH: add np.positive ufunc - #8967

For now, it might be better to skip trying to fix up ndarray.__pos__, and only add the new ufunc for use with NDArrayOperatorsMixin.

Any further concerns here?

Note that I rolled back the changes to ndarray.__pos__

Ah, but needs a release note

Proposal - can all the positive loops be combined into the same template as the negative loops? So add a repeat with @op = +, -@, @func = positive, negative@. Just in the interest of keeping what is an already large file to a somewhat reasonable size.

@shoyer Needs a rebase and release note.

☔ The latest upstream changes (presumably #8885) made this pull request unmergeable. Please resolve the merge conflicts.

Proposal - can all the positive loops be combined into the same template as the negative loops? So add a repeat with @op = +, -@, @func = positive, negative@. Just in the interest of keeping what is an already large file to a somewhat reasonable size.

This is a good idea, but it turned out to be easier said that done:

• For integers, negative uses a non-trivial SIMD trick
• For timedelta, negative needs to check for NaT
• For floats, negative also uses SIMD
• For half, negative also uses something clever

So I just stuck with separate definitions.

Needs a rebase and release note

Done and done.

Thanks @shoyer!

I'm puzzled, this one function does not seem to work well with __array_ufunc__:

class A(np.ndarray):
    def __array_ufunc__(self, ufunc, method, *inputs, **kwargs):
        return "A"

a = np.array(1.).view(A)
-a
# 'A'
+a
# 1.0

I think it is due to positive still being defined as _array_copy_nice in number.c, but simply changing that and adding to GET and SET seemed insufficient:

numpy/core/src/multiarray/number.c:573:50: error: ‘NumericOps {aka struct <anonymous>}’ has no member named ‘positive’; did you mean ‘negative’?
     return PyArray_GenericUnaryFunction(m1, n_ops.positive);

(will try to investigate later, but have to run now; if someone else understands what is happening, do go ahead and fix...)

@shoyer deliberately did not connect up np.positive to __pos__ yet, so I think this is expected behaviour?

OK, rereading the comments I see that is the case. I guess I'll have to keep Quantity.__pos__ for another release then...

@mhvk if you think it would be OK from a compatibility perspective, we could switch ndarray.__pos__. But again, I am concerned that this might cause a minor compatibility break.

Probably being careful is good, but should we at least add the deprecation warning? Also, maybe just pass on to np.positive for classes that define __array_ufunc__? (Since those obviously know what is happening.)

@mhvk Those both sound like fine ideas to me.

@shoyer - would you be able to do it? Or have an idea what I should do beyond what I tried (#8967 (comment))

@mhvk I'm not sure I'll have time to get to this before the branch for 1.13. Probably, the desired behavior is something like:

def __pos__(self):
    try:
        return np.positive(self)
    except TypeError:
        issue deprecation warning
        return self.copy()

(This may be a little tricky, though, because it will need to be done in C.)

For your ndarray subclass, you could overwrite __pos__ to call np.positive, though would probably need a fallback option for older versions of numpy where np.positive is not available.

The override is indeed what I do for Quantity; I'm also not sure I'll have time for another crack at this.

I created #9081 so we don't forget about this.