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 <
m.h.vankerkw...@gmail.com> wrote:
> Just for completeness: this is *not* an issue for ndarray subclass
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 actu
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 wrote:
> Hi All,
>
> I would like to see the numpy.ones_like function operate as a ufunc.
> This i
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]:
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.,
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
NumPy
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 tha
