Changes between Version 32 and Version 33 of MaskedArray

Show
Ignore:
Timestamp:
08/25/07 14:46:23 (6 years ago)
Author:
efiring
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • MaskedArray

    v32 v33  
    33MaskedArray is a numpy ndarray look-alike that allows one to keep track of missing values. 
    44 
    5 MaskedArray is implemented in the [source:trunk/numpy/core/ma.py numpy.core.ma] module.  The numpy ma module is originally written 
     5MaskedArray is implemented in the [source:trunk/numpy/core/ma.py numpy.core.ma] module and also in the maskedarray module in the sandbox (see below).  The numpy ma module is originally written 
    66for Numeric by Paul Dubois and adapted for numpy by Travis Oliphant and 
    77(mainly) Paul Dubois. 
     
    154154'''Note: the new implementation of MaskedArray is now available in the scipy sandbox. ''' 
    155155 
    156 As a regular user of MaskedArray, I became increasingly frustrated with the subclassing of masked arrays (even if I can only blame my inexperience). I needed to develop a class of arrays that could store some additional information along with numerical values, while keeping the possibility for missing data (picture storing a series of dates along with measurements). I started to implement such a class, but then quickly realized that any additional information disappeared when processing these subarrays (for example, adding a constant value to a subarray would erase its dates). I ended up writing the equivalent of {{{numpy.core.ma}}} for my particular class, ufuncs included. Everything went fine until I needed to subclass my new class, when more problems showed up: some attributes of the new subclass were lost during processing. I identified the culprit as MaskedArray, which returns masked ndarrays when I expected masked arrays of my class. I was preparing myself to rewrite numpy.core.ma when I forced myself to learn how to subclass ndarrays. As I became more familiar with the {{{__new__}}} and {{{__array_finalize__}}} methods, I started to wonder why masked arrays were objects, and not ndarrays, and whether it wouldn't be more convenient for subclassing if they did behave like regular ndarrays. 
     156As a regular user of MaskedArray, I (Pierre G.F. Gerard-Marchant) became increasingly frustrated with the subclassing of masked arrays (even if I can only blame my inexperience). I needed to develop a class of arrays that could store some additional information along with numerical values, while keeping the possibility for missing data (picture storing a series of dates along with measurements). I started to implement such a class, but then quickly realized that any additional information disappeared when processing these subarrays (for example, adding a constant value to a subarray would erase its dates). I ended up writing the equivalent of {{{numpy.core.ma}}} for my particular class, ufuncs included. Everything went fine until I needed to subclass my new class, when more problems showed up: some attributes of the new subclass were lost during processing. I identified the culprit as MaskedArray, which returns masked ndarrays when I expected masked arrays of my class. I was preparing myself to rewrite numpy.core.ma when I forced myself to learn how to subclass ndarrays. As I became more familiar with the {{{__new__}}} and {{{__array_finalize__}}} methods, I started to wonder why masked arrays were objects, and not ndarrays, and whether it wouldn't be more convenient for subclassing if they did behave like regular ndarrays. 
    157157 
    158158The new {{{maskedarray}}} is what I eventually come up with. The main differences with the initial {{{numpy.core.ma}}} package are that {{{MaskedArray}}} is now a subclass of {{{ndarray}}} and that the {{{_data}}} section can now be any subclass of {{{ndarray}}} (well, it should work in most cases, some tweaking might required here and there). Apart from a couple of issues listed below, the behavior of the new {{{MaskedArray}}} class reproduces the old one. Initially the maskedarray implementation was marginally slower than numpy.ma in some areas, but work is underway to speed it up; the expectation is that it can be made substantially faster than the present numpy.ma.