[Numpy-discussion] Re: ndarray.fill and ma.array.filled

Pierre GM pgmdevlist at mailcan.com
Fri Apr 7 16:13:02 CDT 2006

> filled:
> 1. I don't like default fill value.   It should  be mandatory to
> supply fill value.

> 2. It should return masked array (with trivial mask), not ndarray.
-1. Unless 'mask/missing/na' becomes a default in ndarray, and other basic 
ndarray functions know how to deal with MA seamlessly

> 3. The name conflicts with the "fill" method.
fillmask ? clog ?

> 4. View/Copy inconsistency.  Does not provide a method to fill values
> in-place.
But once again, I don't think it should be the default behaviour ! A filled 
array should always be a copy of the initial array. Changing in place means 
changing the initial data, and I foresee lots of fun to find the original 
back. No ctrl+Z.

> mask:
> 1. I've got rid of mask returning None in favor of False_ (boolean
> array scalar), but it is still not perfect.  I would prefer data.shape
> == mask.shape invariant and if space saving/performance  is deemed
> necessary use zero-stride arrays.
You,lost me on the strides, but I agree with data.shape==mask.shape as a std

> 2. I don't like the name. "Missing" or "na" would be better.
Once again, it's a point of view. Masked data also means 'data that I don't 
wanna see now, but that I may want to see later'. Like masking an 
bitmap/raster area. +0 for na, no for missing.

>  I would not object making mask read only, however.
Good point. but I was more and more thinking of the opposite. I have a set of 
data that I group in three classes. Plotting one class is straightforward, I 
just have to mask the other two. Do I really want/need three objects for the 
same data ? Can't I just save three masks, and then run a data[mask] ? 

> If existing MA interface is rejected (which is
> likely) for ndarray, we can easily experiment with the alternatives
> within MA, which is pure python.

Er... How many of us are using MA on a regular basis ? Aren't we a minority ?
It'd seem wiser to adapt MA to numpy, in Python (but maybe that's the XIXe 
French integration model I grew up with that makes me talk here...)

More information about the Numpy-discussion mailing list