On 31-Dec-2014 4:53 am, "Nathaniel Smith" <[email protected]> wrote: > > On Tue, Dec 30, 2014 at 10:56 PM, Benjamin Root <[email protected]> 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 > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
