Re: [Numpy-discussion] Turn numpy.ones_like into a ufunc

[Nathaniel Smith]

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 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
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Turn numpy.ones_like into a ufunc

[Hameer Abbasi]

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 
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 NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 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 <
m.h.vankerkw...@gmail.com> 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
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 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
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] 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
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NumPy sprint May 24-25 at BIDS

[Stephan Hoyer]

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, 2018 at 4:37 PM Jaime Fernández del Río <
> jaime.f...@gmail.com> wrote:
>
>> OK, make that all day Friday only, if it's Friday and Saturday.
>>
>> Jaime
>>
>> On Thu, May 17, 2018 at 4:36 PM Jaime Fernández del Río <
>> jaime.f...@gmail.com> wrote:
>>
>>> Hi Matti,
>>>
>>> I will be joining you on Thursday, sometime around noon, and all day
>>> Friday.
>>>
>>> Jaime
>>>
>>> On Thu, May 17, 2018 at 4:11 PM Matti Picus 
>>> wrote:
>>>
 On 09/05/18 13:33, Matti Picus wrote:
 > A reminder - we will take advantage of a few NumPy developers being
 at
 > Berkeley to hold a two day sprint May 24-25
 > https://scisprints.github.io/#may-numpy-developer-sprint
 > .
 > We invite any core contributors who would like to attend and can help
 > if needed with travel and accomodations.
 >
 > Stefan and Matti
 So far I know about Stefan, Nathaniel, Chuck and me. Things will work
 better if we can get organized ahead of time. Anyone else planning on
 attending for both days or part of the sprint, please drop me a line.
 If
 there are any issues, pull requests, NEPs, or ideas you would like us
 to
 work on please let me know, or add it to the Trello card
 https://trello.com/c/fvSYkm2w

 Matti
 ___
 NumPy-Discussion mailing list
 NumPy-Discussion@python.org
 https://mail.python.org/mailman/listinfo/numpy-discussion

>>>
>>>
>>> --
>>> (\__/)
>>> ( O.o)
>>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus
>>> planes de dominación mundial.
>>>
>>
>>
>> --
>> (\__/)
>> ( O.o)
>> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
>> de dominación mundial.
>>
>
>
> --
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes
> de dominación mundial.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion