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.modesty...@gmail.com> wrote: > > On 31-Dec-2014 4:53 am, "Nathaniel Smith" <n...@pobox.com> wrote: > > > > On Tue, Dec 30, 2014 at 10:56 PM, Benjamin Root <ben.r...@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@scipy.org > > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
