[Numpy-discussion] Clarifications in numpy.ma module
maniteja.modesty067 at gmail.com
Tue Dec 30 18:34:52 EST 2014
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
> > 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
> > or Inf, so that is probably why the division was different from the
> > This confusion probably came about in conflating valid-ness with NaN
> > as concepts. In small parts of the codebase, it seems to operate with
> > concept that NaN === invalid, while other parts strictly works within
> > framework of masked === invalid.
> > Of course, fixing any of this would be potentially a significant change
> > behavior. I am certainly not one to make any sort of determination on
> > 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. :-)
> Nathaniel J. Smith
> Postdoctoral researcher - Informatics - University of Edinburgh
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion