On Fri, Jul 1, 2011 at 3:07 PM, Eric Firing <efir...@hawaii.edu> wrote:
> On 07/01/2011 10:27 AM, Charles R Harris wrote: > > > > > > On Fri, Jul 1, 2011 at 1:39 PM, Christopher Barker > > <chris.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>> wrote: > > > > Joe Harrington wrote: > > > All > > > that has to happen is to allow the sense of the mask to be FALSE > > = the > > > data are bad, TRUE = the data are good, and allow (not require) > the > > > mask to be of any numerical type, or at least of integer type as > well > > > as boolean. > > > > quick note on this: I like the "FALSE == good" way, because: > > > > instead of good and bad we think "masked" and "unmasked", then we > have: > > > > False = "unmasked" = "regular old data" > > True = "masked" = "something special about the data > > > > The default for "something special" is "bad" (or "missing" , or > > "ignore"), but the cool thing is that if you use an int: > > > > 0 = "unmasked" > > 1 = "masked because of one thing" > > 2 = "masked because of another" > > etc., etc. > > > > This could be pretty powerful > > > > > > I don't think the false/true dichotomy isn't something to worry about, > > it is an implementation detail that is hidden from the user... > > But Joe's point and Chris's seemingly opposite (in terms of the Boolean > value of the mask) point are that if it is not completely hidden, and if > it is not restricted to be Boolean but is merely treated as Boolean with > True meaning NA or Ignore, then it can be more powerful because it can > carry additional information without affecting its Boolean functionality > as a mask in ufuncs. > > Although I might use such a capability if it existed, to reduce the need > to have a separate flags array corresponding to a given data array, I > think that for my own purposes this is very low priority, and chances > are I would often use a separate flags array even if the underlying mask > were not restricted to Boolean. > > Array access needs to be distinguished from array exposure. If the access goes through getter/setter functions than the underlying representation can change. Whether or not that degree of abstraction is needed is another question, but it does make things more flexible. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
