> > Availability of the NaN functionality in a method of ndarray > > The last point is key. The NaN behavior is central to analyzing real > data containing unavoidable bad values, which is the bread and butter > of a substantial fraction of the user base. In the languages they're > switching from, handling NaNs is just part of doing business, and is > an option of every relevant routine; there's no need for redundant > sets of routines. In contrast, numpy appears to consider data > analysis to be secondary, somehow, to pure math, and takes the NaN > functionality out of routines like min() and std(). This means it's > not possible to use many ndarray methods. If we're ready to handle a > NaN by returning it, why not enable the more useful behavior of > ignoring it, at user discretion? >
Maybe I missed this somewhere, but this seems like a better use for masked arrays, not NaN's. Masked arrays were specifically designed to add functions that work well with masked/invalid data points. Why reinvent the wheel here? Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
