Re: [Numpy-discussion] Splitting MaskedArray into a separate package

Disclaimer : this is a user's point of view. I never commited a line in numpy. In my usage, missing values happen or the need for some kind of mask, such as sea/land. I've been told, here, that using MA is superior to using NaNs, and indeed, I found a couple case where other libraries

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

Hi All, I agree with comments above that deprecating/removing MaskedArray is premature; we certainly depend on it in astropy (which is indeed what got me started to contribute to numpy -- it was quite buggy!). I also think that, unlike Matrix, it is far from a neglected part of numpy. Eric

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On 05/24/2018 11:31 AM, Sebastian Berg wrote: > I also somewhat like the idea of taking it out (once we have a first > replacement) in the case that we have a plan to do a better/lower level > replacement at a later point within numpy. > Removal generally has its merits, but if a (mid term)

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On Wed, 2018-05-23 at 23:48 +0200, Sebastian Berg wrote: > On Wed, 2018-05-23 at 17:33 -0400, Allan Haldane wrote: > > If we do not plan to replace it within numpy, we need to discuss a > bit > how it might affect infrastructure (multiple implementations). > > There is the other

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

As further evidence of a widely used package that is often considered "critical" to an ecosystem that gets negligible support, look no further than Basemap. It went almost two years without any commits before I took it up (and then only because my employer needed a couple of fixes). I worry that

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

Hi Eric, On Wed, 23 May 2018 10:02:22 -1000, Eric Firing wrote: > Masked arrays are critical to my numpy usage, and I suspect they are > critical for many other use cases as well. That's good to know; and the goal of this NEP should be to improve your siatuion, not make it worse. > In fact, I

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

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

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

Hi, On Wed, May 23, 2018 at 10:42 PM, Stefan van der Walt wrote: > On May 23, 2018 14:28:05 Matthew Brett wrote: >> >> >> Can I ask what the plans are for supporting missing values, inside or >> outside numpy? Is there are successor to MaskedArray

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On Wed, 2018-05-23 at 17:33 -0400, Allan Haldane wrote: > On 05/23/2018 04:02 PM, Eric Firing wrote: > > Bad or missing values (and situations where one wants to use a mask > > to > > operate on a subset of an array) are found in many domains of real > > life; > > do you really want python users

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On May 23, 2018 14:28:05 Matthew Brett wrote: Can I ask what the plans are for supporting missing values, inside or outside numpy? Is there are successor to MaskedArray - and is this part of the succession plan? I am not aware of any concrete plans, maybe others can

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On 05/23/2018 04:02 PM, Eric Firing wrote: > Bad or missing values (and situations where one wants to use a mask to > operate on a subset of an array) are found in many domains of real life; > do you really want python users in those domains to have to fall back on > Matlab-style reliance on nans

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

Hi, On Wed, May 23, 2018 at 9:51 PM, Stefan van der Walt wrote: > Hi Eric, > > On May 23, 2018 13:25:44 Eric Firing wrote: > >> On 2018/05/23 9:06 AM, Matti Picus wrote: >> I understand at least some of the motivation and potential advantages, >> but

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

As far as I understand from the discussion above, I think the opposite would be a better strategy for the sanity of our scarce but brave maintainers. I would argue that if there is a maintenance burden, then the ballasts seem to be the linalg and random indeed. Similar pain points exist in SciPy

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

Hi Eric, On May 23, 2018 13:25:44 Eric Firing wrote: On 2018/05/23 9:06 AM, Matti Picus wrote: I understand at least some of the motivation and potential advantages, but as it stands, I find this NEP highly alarming. I am not at my computer right now, so I will respond

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On Wed, May 23, 2018 at 1:03 PM, Stefan van der Walt wrote: > On Wed, 23 May 2018 12:29:32 -0700, Ralf Gommers wrote: > > >> * Compatibility: MaskedArray objects, being subclasses of `ndarrays`, > > >>often cause complications when being used with other packages. > >

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On 2018/05/23 9:06 AM, Matti Picus wrote: MaskedArray is a strange but useful creature. This NEP proposes to distribute it as a separate package under the NumPy brand. As I understand the process, a proposed NEP should be first discussed here to gauge general acceptance, then after that the

Re: [Numpy-discussion] Splitting MaskedArray into a separate package

On Wed, 23 May 2018 12:29:32 -0700, Ralf Gommers wrote: > >> * Compatibility: MaskedArray objects, being subclasses of `ndarrays`, > >>often cause complications when being used with other packages. > >>Fixing these issues is outside the scope of NumPy development. > > > Hmm, I wouldn't

[Numpy-discussion] Splitting MaskedArray into a separate package

MaskedArray is a strange but useful creature. This NEP proposes to distribute it as a separate package under the NumPy brand. As I understand the process, a proposed NEP should be first discussed here to gauge general acceptance, then after that the details should be discussed on the pull