Turn numpy.ones_like into a ufunc

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Turn numpy.ones_like into a ufunc

Matthew Rocklin
Hi All,

I would like to see the numpy.ones_like function operate as a ufunc.  This is currently done in np.core.umath._ones_like.  This was recently raised and discussed in https://github.com/numpy/numpy/issues/11074 .  It was suggested that I raise the topic here instead.

My understanding is that this was considered some time ago, but that the current numpy.ones_like function was implemented instead.  No one on that issue seems to fully remember why.  Perhaps someone here has a longer memory?

My objective for defaulting to the ufunc implementation is that it makes it compatible with other projects that implement numpy-like interfaces (dask.array, sparse, cupy) so that downstream projects can use a subset of numpy code that is valid across a few projects.  More broadly I would like to see ufuncs and other protocol-enabled functions start to become more common within numpy, ones_like being one specific case.

Best,
-matt

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Turn numpy.ones_like into a ufunc

Marten van Kerkwijk
I'm greatly in favour, especially if the same can be done for
`zeros_like` and `empty_like`, but note that a tricky part is that
ufuncs do not deal very graciously with structured (void) and string
dtypes. -- Marten
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Turn numpy.ones_like into a ufunc

Nathan Goldbaum
I don't particularly need this, although it would be nice to make this behavior explicit, instead of happening more or less by accident:

    In [1]: from yt.units import km

    In [2]: import numpy as np

    In [3]: data = [1, 2, 3]*km

    In [4]: np.ones_like(data)
    Out[4]: YTArray([1., 1., 1.]) km


On Fri, May 18, 2018 at 9:51 AM, Marten van Kerkwijk <[hidden email]> wrote:
I'm greatly in favour, especially if the same can be done for
`zeros_like` and `empty_like`, but note that a tricky part is that
ufuncs do not deal very graciously with structured (void) and string
dtypes. -- Marten
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Turn numpy.ones_like into a ufunc

einstein.edison
You can preserve this with (for example) __array_ufunc__. On
18/05/2018 at 18:57, Nathan wrote: I don't particularly need this,
although it would be nice to make this behavior explicit, instead of
happening more or less by accident: In [1]: from yt.units import km In
[2]: import numpy as np In [3]: data = [1, 2, 3]*km In [4]:
np.ones_like(data) Out[4]: YTArray([1., 1., 1.]) km On Fri, May 18,
2018 at 9:51 AM, Marten van Kerkwijk <[hidden email]>
wrote: I'm greatly in favour, especially if the same can be done for
`zeros_like` and `empty_like`, but note that a tricky part is that
ufuncs do not deal very graciously with structured (void) and string
dtypes. -- Marten _______________________________________________
NumPy-Discussion mailing list [hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Turn numpy.ones_like into a ufunc

Nathaniel Smith
In reply to this post by Matthew Rocklin
I would like to see a plan for how we're going to handle zeroes_like, empty_like, ones_like, and full_like before we start making changes to any of them.

On Fri, May 18, 2018, 05:33 Matthew Rocklin <[hidden email]> wrote:
Hi All,

I would like to see the numpy.ones_like function operate as a ufunc.  This is currently done in np.core.umath._ones_like.  This was recently raised and discussed in https://github.com/numpy/numpy/issues/11074 .  It was suggested that I raise the topic here instead.

My understanding is that this was considered some time ago, but that the current numpy.ones_like function was implemented instead.  No one on that issue seems to fully remember why.  Perhaps someone here has a longer memory?

My objective for defaulting to the ufunc implementation is that it makes it compatible with other projects that implement numpy-like interfaces (dask.array, sparse, cupy) so that downstream projects can use a subset of numpy code that is valid across a few projects.  More broadly I would like to see ufuncs and other protocol-enabled functions start to become more common within numpy, ones_like being one specific case.

Best,
-matt
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Turn numpy.ones_like into a ufunc

Marten van Kerkwijk
Just for completeness: this is *not* an issue for ndarray subclasses,
but only for people attempting to write duck arrays.  One might want
to start by mimicking `empty_like` - not too different from
`np.positive(a, where=False)`. Will note that that is 50 times slower
for small arrays since it actually does the copying - it just doesn't
store the results. It is comparable in time to np.zeros_like and
np.ones_like, suggesting
that a ufunc implementation is not necessarily a bad thing.

As I noted above, the main problem I see is that the ufunc mechanism
doesn't easily work with strings and voids/structured dtypes.

-- Marten
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Turn numpy.ones_like into a ufunc

Matthew Rocklin
I've also posted a second issue on doing this at the module level (beyond just ones_like) here: https://github.com/numpy/numpy/issues/11129

On Sat, May 19, 2018 at 9:12 PM, Marten van Kerkwijk <[hidden email]> wrote:
Just for completeness: this is *not* an issue for ndarray subclasses,
but only for people attempting to write duck arrays.  One might want
to start by mimicking `empty_like` - not too different from
`np.positive(a, where=False)`. Will note that that is 50 times slower
for small arrays since it actually does the copying - it just doesn't
store the results. It is comparable in time to np.zeros_like and
np.ones_like, suggesting
that a ufunc implementation is not necessarily a bad thing.

As I noted above, the main problem I see is that the ufunc mechanism
doesn't easily work with strings and voids/structured dtypes.

-- Marten
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion