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
I will also be attending, on at least Thursday (and hopefully Friday, too).
Best,
Stephan
On Thu, May 17, 2018 at 1:40 PM Jaime Fernández del Río <
jaime.f...@gmail.com> wrote:
> $#!#, was looking at the wrong calendar month: Thursday half day, Friday
> all day.
>
> Jaime
>
> On Thu, May 17, 201
