Helge Avlesen wrote:
regarding the support for NaN's; are there plans to use that functionality
instead of masked arrays in matplotlib routines like pcolor, contour etc.?
solid support for Nan's ala matlab would be good imo., as I always
seem to run into problems with array operations after some array has
I think we will want to have solid support for NaNs *and* masked arrays. Note that NaNs are restricted to floating point; masked arrays are much more general, and have some other advantages. (Coming from Matlab, I started out as a fan of NaNs, but I have come to appreciate the masked array approach. The more tightly it becomes integrated in numpy, the better.)
I have not thought through the implementation yet. I have been thinking that the time to make big changes in this area will be when we can drop Numeric and numarray support in favor of numpy. Then we will only have to keep track of a single masked array implementation, and a single set of NaN-handling facilities.
As a possibly interim step, it would not be hard to convert arrays with NaNs to masked arrays at the argument processing stage of functions that already handle masked arrays. If numerix.isnan now works for all supported numeric flavors, then I could do this when I get to a suitable point in my axes.py reorganization. Alternatively, it can be done externally be the user.
There is ongoing work on the numpy side to reduce--eliminate, I hope--problems such as you refer to, where things go haywire when you use a masked array.