[Numpy-discussion] Clarifications in numpy.ma module

[Maniteja Nandana]

On 31-Dec-2014 4:53 am, "Nathaniel Smith" <njs at pobox.com> wrote:
>
> On Tue, Dec 30, 2014 at 10:56 PM, Benjamin Root <ben.root at ou.edu> wrote:
> > exception? Did you mean warning? If warning, I recall some discussion
> > recently to figure out a way to hide that, but only for masked values (I
> > would want to see the warning if I do bad calculations in the unmasked
> > portions of my array).
> >
I was referring to the warning. I thought it could be handled elegantly.
Yeah I do get the warning serves as reminder to the user.

> > Now I see your point 3 much more clearly. I had never noticed that the
> > divide could produce new masked elements. It is presumptuous to assume
that
> > NaNs are what I want masked. Division (and exponential) are the only two
> > binary operations I can imagine where two valid floats could produce a
NaN
> > or Inf, so that is probably why the division was different from the
others.
> > This confusion probably came about in conflating valid-ness with NaN
and Inf
> > as concepts. In small parts of the codebase, it seems to operate with
the
> > concept that NaN === invalid, while other parts strictly works within
the
> > framework of masked === invalid.
> >
> > Of course, fixing any of this would be potentially a significant change
in
> > behavior. I am certainly not one to make any sort of determination on
this.
> > I am just a heavy user of masked arrays.
>
I was just thinking if there was a uniform policy for handling NaN and inf.

> Unfortunately, as we discovered during the NA debate, it turns out
> that there are several different ways to think about masked/missing
> values, and np.ma kinda can't decide which one it wants to implement
> so it implements a mix of all of them. This makes it difficult to know
> whether it's working correctly or not :-).
>
I actually got the last point since I was not sure about the operator
overloading,for eg,  whether a/b would be equal to np.ma.divide (a, b) or
np.divide (a, b).

> @Maniteja: Also unfortunately (and probably not unrelatedly) the np.ma
> code is mostly pretty old and receives only minimal maintenance. So if
> you don't receive answers to your original questions it may just be
> that there's no-one around who knows. "It works that way because
> that's the way it works"... (My personal recommendation is to steer
> clear of using np.ma entirely, but reasonable people can disagree.)

Thanks for the info, but I was just trying to get a idea of the source code
and I have had some exposure previously to np.ma, but never found these
issues until I looked at the core. :-)
>
> -n
>
> --
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> http://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20141231/9ba7f7eb/attachment.html>