also suggest to avoid those functions for which
> ufunc implementations would seem quite possible (i.e., avoid things like
> median, etc.)
>
> All the best,
>
> Marten
>
> On Wed, Aug 29, 2018 at 8:31 AM Matthew Rocklin
> wrote:
>
>> >> 1. if we do find our
>> 1. if we do find ourselves in a situation where changing this would
break lots of users, will we consider ourselves beholden to them?
I think that it would be useful for Numpy's continued evolution to develop
the ability to include code on a provisional basis. Other projects do this
and they j
Hi Nathaniel,
I appreciate the clarification. Thank you for that. For what it's worth,
I think that you may overestimate my involvement in the writing of that
NEP. I sat down with Stephan during a Numpy dev meeting and we hacked
something together. Afterwards several other people poured their
Hi All,
*Disclaimer: I don't spend any hours actually maintaining Numpy, so please
don't take my comments here with much weight.*
My gut reaction here is that if removing masked array allows Numpy to
evolve more quickly then this excites me.
It could be that a plan goes something like the follow
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
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
FWIW I'll be at BIDS on the 25th, though I'll mostly be working on
non-Numpy things.
On Thu, May 17, 2018 at 7: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
I'm very glad to see this discussion.
I think that coming up with a single definition of array-like may be
difficult, and that we might end up wanting to embrace duck typing instead.
It seems to me that different array-like classes will implement different
mixtures of features. It may be difficu
How would the community handle the scipy.sparse matrix subclasses? These
are still in common use.
Somewhat related: https://github.com/scipy/scipy/issues/8162
On Thu, Nov 30, 2017 at 1:13 PM, wrote:
>
>
> On Thu, Nov 30, 2017 at 9:23 AM, Marten van Kerkwijk <
> m.h.vankerkw...@gmail.com> wrote
rrays are np.ndarrays. It would be nice to ensure that the container
type was swappable.
On Sat, Nov 25, 2017 at 6:31 PM, Matthew Rocklin wrote:
> Can you make a case for the usefulness numpy annotations? What benefits to
> you want to achieve and how will annotation aid in getting there.
Can you make a case for the usefulness numpy annotations? What benefits to
you want to achieve and how will annotation aid in getting there.
1. Error checking on large codebases with systems like MyPy
2. Hinting and error checking at code-writing time with systems like
Jedi "Hey, this fu
11 matches
Mail list logo
