On Fri, Jun 14, 2013 at 6:40 PM, Benjamin Root <ben.root@ou.edu> wrote:
On Fri, Jun 14, 2013 at 1:22 PM, Nathaniel Smith <njs@pobox.com> wrote:
On 2013/06/12 2:10 AM, Nathaniel Smith wrote: Despite heroic efforts on the part of its authors, numpy.ma has a number of weird quirks (masked data can still trigger invalid value errors), misfeatures (hard versus soft masks), and just plain old pain
On Wed, Jun 12, 2013 at 7:43 PM, Eric Firing <efiring@hawaii.edu> wrote: points (ongoing issues with whether any given operation will respect or preserve the mask).
Actually, now that we have a context manager for warning capture, we could actually fix that.
PRs welcome!
It's been in deep maintenance mode for some time; we merge the occasional bug fix that people send in, and that's it. (To be fair, numpy as a whole is fairly slow-moving, but numpy.ma still gets much less attention.)
Even if there were active maintainers, no-one really has any idea how to fix any of the problems above; they're not so much bugs as intrinsic limitations of the design.
Therefore, my impression is that a majority (not all, but a majority) of numpy developers strongly recommend against the use of numpy.ma in new projects.
Such a recommendation should be in writing in the documentation and elsewhere.
Maybe, but someone needs to write it, and in a way that gets past the list. Feel free to try :-).
Furthermore, a proper replacement would also be needed. Just simiply deprecating it without some sort of decent alternative leaves everybody in a lurch. I have high hopes for NA to be that replacement, and the sooner, the better.
Again, this would be great, just, someone needs to do it :-).
But, IMHO given the issues with numpy.ma, our number #1 priority ought to be making numpy proper as clean and beautiful as possible; my position that started this thread is basically just that we shouldn't make numpy proper worse just for numpy.ma's sake. That's the tail wagging the dog. And this 'conflict' seems a bit overstated given that (1) np.ma.filled already has multiple names (and 3/4 of the uses in matplotlib use the method version, not the function version), (2) even if we give it a non-conflicting name, np.ma's lack of maintenance means that it'd probably be years before someone got around to actually adding a parallel function to np.ma. [Unless this thread spurs someone into submitting one just to prove me wrong ;-).]
Actually, IIRC, np.ma does some sort of auto-wrapping of numpy functions. This is why adding np.filled() would cause a namespace clobbering, I think.
Nope. np.ma manually wraps and re-exports every object that it exports. Generally speaking it has to, because there's no way to look at an arbitrary numpy function and know what the np.ma equivalent would be. But even in cases where auto-wrapping would be possible and useful, it doesn't do it. (E.g., it's easy to get a list of all ufunc objects in the np.* namespace and wrap them all automatically, but np.ma doesn't, it just has a big and possibly out-of-date list of all the ufuncs that it knows about.) -n