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 <mrock...@gmail.com> 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