![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
Hi All, Does anyone remember discussion of numpy scalars apropos __numpy_ufunc__? Chuck
![](https://secure.gravatar.com/avatar/93a76a800ef6c5919baa8ba91120ee98.jpg?s=120&d=mm&r=g)
I'm happy to revisit the __numpy_ufunc__ discussion (I still want to see it happen!), but I don't recall scalars being a point of contention. The obvious thing to do with scalars would be to treat them the same as 0-dimensional arrays, though I might be missing some nuance... On Sat, Oct 29, 2016 at 6:02 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Sat, Oct 29, 2016 at 7:03 PM, Stephan Hoyer <shoyer@gmail.com> wrote:
I'm happy to revisit the __numpy_ufunc__ discussion (I still want to see it happen!), but I don't recall scalars being a point of contention.
The __numpy_ufunc__ functionality is the last bit I want for 1.12.0, the rest of the remaining changes I can kick forward to 1.13.0. I will start taking a look tomorrow, probably starting with Nathaniel's work.
The obvious thing to do with scalars would be to treat them the same as 0-dimensional arrays, though I might be missing some nuance...
That's my thought. Currently they just look at __array_priority__ and call the corresponding array method if needed, so that maybe needs some improvement and a formal statement of intent. Chuck
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Chuck, I've revived my Quantity PRs that use __numpy_ufunc__ but is it correct that at present in *dev, one cannot use it? All the best, Marten
![](https://secure.gravatar.com/avatar/93a76a800ef6c5919baa8ba91120ee98.jpg?s=120&d=mm&r=g)
Recall that I think we wanted to rename this to __array_ufunc__, so we could change the function signature: https://github.com/numpy/numpy/issues/5986 I'm still a little nervous about this. Chunk -- what is your proposal for resolving the outstanding issues from https://github.com/numpy/numpy/issues/5844? On Mon, Oct 31, 2016 at 10:31 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Oct 31, 2016 at 11:39 AM, Stephan Hoyer <shoyer@gmail.com> wrote:
We were pretty close. IIRC, the outstanding issue was some sort of override. At the developer meeting at scipy 2015 it was agreed that it would be easy to finish things up under the rubric "make Pauli happy". But that wasn't happening which is why I asked Nathaniel to disable it for 1.10.0. It is now a year later, things have cooled, and, IMHO, it is time to take another shot at it. <snip> Chuck
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Chuck,
We were pretty close. IIRC, the outstanding issue was some sort of override.
Correct. With a general sentiment of those downstream that it would be great to merge in any form, as it will be really helpful! (Generic speedup of factor of 2 for computationally expensive ufuncs (sin, cos, etc.) that needs scaling in Quantity...)
At the developer meeting at scipy 2015 it was agreed that it would be easy to finish things up under the rubric "make Pauli happy".
That would certainly make me happy too! Other items that were brought up (trying to summarize from issues linked above, and links therein): 1. Remove index argument 2. Out always a tuple 3. Let ndarray have a __numpy_ufunc__ stub, so one can super it. Here, the first item implied a possible name change (to __array_ufunc__); if that's too troublesome, I don't think it really hurts to have the argument, though it is somewhat "unclean" for the case that only the output has __numpy_ufunc__. All the best, Marten
![](https://secure.gravatar.com/avatar/93a76a800ef6c5919baa8ba91120ee98.jpg?s=120&d=mm&r=g)
I'm happy to revisit the __numpy_ufunc__ discussion (I still want to see it happen!), but I don't recall scalars being a point of contention. The obvious thing to do with scalars would be to treat them the same as 0-dimensional arrays, though I might be missing some nuance... On Sat, Oct 29, 2016 at 6:02 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Sat, Oct 29, 2016 at 7:03 PM, Stephan Hoyer <shoyer@gmail.com> wrote:
I'm happy to revisit the __numpy_ufunc__ discussion (I still want to see it happen!), but I don't recall scalars being a point of contention.
The __numpy_ufunc__ functionality is the last bit I want for 1.12.0, the rest of the remaining changes I can kick forward to 1.13.0. I will start taking a look tomorrow, probably starting with Nathaniel's work.
The obvious thing to do with scalars would be to treat them the same as 0-dimensional arrays, though I might be missing some nuance...
That's my thought. Currently they just look at __array_priority__ and call the corresponding array method if needed, so that maybe needs some improvement and a formal statement of intent. Chuck
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Chuck, I've revived my Quantity PRs that use __numpy_ufunc__ but is it correct that at present in *dev, one cannot use it? All the best, Marten
![](https://secure.gravatar.com/avatar/93a76a800ef6c5919baa8ba91120ee98.jpg?s=120&d=mm&r=g)
Recall that I think we wanted to rename this to __array_ufunc__, so we could change the function signature: https://github.com/numpy/numpy/issues/5986 I'm still a little nervous about this. Chunk -- what is your proposal for resolving the outstanding issues from https://github.com/numpy/numpy/issues/5844? On Mon, Oct 31, 2016 at 10:31 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
![](https://secure.gravatar.com/avatar/96dd777e397ab128fedab46af97a3a4a.jpg?s=120&d=mm&r=g)
On Mon, Oct 31, 2016 at 11:39 AM, Stephan Hoyer <shoyer@gmail.com> wrote:
We were pretty close. IIRC, the outstanding issue was some sort of override. At the developer meeting at scipy 2015 it was agreed that it would be easy to finish things up under the rubric "make Pauli happy". But that wasn't happening which is why I asked Nathaniel to disable it for 1.10.0. It is now a year later, things have cooled, and, IMHO, it is time to take another shot at it. <snip> Chuck
![](https://secure.gravatar.com/avatar/851ff10fbb1363b7d6111ac60194cc1c.jpg?s=120&d=mm&r=g)
Hi Chuck,
We were pretty close. IIRC, the outstanding issue was some sort of override.
Correct. With a general sentiment of those downstream that it would be great to merge in any form, as it will be really helpful! (Generic speedup of factor of 2 for computationally expensive ufuncs (sin, cos, etc.) that needs scaling in Quantity...)
At the developer meeting at scipy 2015 it was agreed that it would be easy to finish things up under the rubric "make Pauli happy".
That would certainly make me happy too! Other items that were brought up (trying to summarize from issues linked above, and links therein): 1. Remove index argument 2. Out always a tuple 3. Let ndarray have a __numpy_ufunc__ stub, so one can super it. Here, the first item implied a possible name change (to __array_ufunc__); if that's too troublesome, I don't think it really hurts to have the argument, though it is somewhat "unclean" for the case that only the output has __numpy_ufunc__. All the best, Marten
participants (3)
-
Charles R Harris
-
Marten van Kerkwijk
-
Stephan Hoyer