[Numpy-discussion] Clarifications in numpy.ma module

Benjamin Root ben.root at ou.edu
Tue Dec 30 20:40:49 EST 2014


Maniteja,

Careful with advertising that you are reading up on any under-maintained
codebases. I did that for mplot3d four years ago and the previous
maintainer said "tag! you're it!"

I haven't been able to tag anyone since then...

Cheers!
Ben Root


On Tue, Dec 30, 2014 at 6:34 PM, Maniteja Nandana <
maniteja.modesty067 at gmail.com> wrote:

>
> 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
>
> _______________________________________________
> 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/20141230/bf34d5e5/attachment.html>


More information about the NumPy-Discussion mailing list