Pierre GM wrote: [...] > > David, I wouldn't speak about compatibility, just about bugs: the problem was > in the implementation of .max() w/ maskedarray. The origin of the problem was > (is still) in umath.maximum.reduce that doesn't accept axis=None, so a numpy > problem ;). But I agree: switching may have some subtle consequences in > matplotlib (nothing that can't be quickly fiexed, however). What do Eric > Firing, John Hunter and the other mpl developer think ? I think this would be a good time to make the switch. We are going to be stripping out the Numeric and numarray support, so let's finalize the new ma capabilities at the same time. I think that maskedarray is actually closer to being a drop-in replacement for ndarray than ma is, and I think it will be easier to work with. I am confident that any problems can be solved easily. A 15% speed penalty doesn't bother me; presumably it can be reduced later. > > My only request would be for more users ! That's the only way I can find how > to improve maskedarray. Moving maskedarray from the sandbox into svn numpy will make it easier for mpl devels to use it while doing and testing the mpl numpification. (I won't be able to work on this until June.) I suppose that it will be necessary for mpl to support both for a while, unfortunately, but I haven't thought this through carefully. Eric