Darren Dale wrote: > On Thursday 15 November 2007 06:12:32 pm Eric Firing wrote: >> [EMAIL PROTECTED] wrote: >>> Revision: 4325 >>> >>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=4325&view=rev >>> Author: dsdale >>> Date: 2007-11-15 13:23:27 -0800 (Thu, 15 Nov 2007) >>> >>> Log Message: >>> ----------- >>> added npy.seterr(invalid='ignore') to beginning of axes.py, to silence >>> repeated warnings created by finding extrema of arrays containing nans >>> (discovered during calls to errorbar) >> Darren, >> >> Is this hiding a problem that will pop up farther down the line? > > I don't know, this problem was pretty well hidden to begin with. I consider > it > a bug that numpy doesnt gracefully handle finding the extrema of an array > that containing nans. Why should this warrant a warning?
There are major differences of opinion, or differences of application, as to how nans and other floating point oddities should be handled. As a result, numpy was designed to allow the user to specify how floating point exceptions should be handled. Matlab-style handling of nans--which I have always found enormously useful in Matlab--imposes a significant computational cost, and neither the style nor the cost is acceptable to a substantial fraction of the numpy community. Therefore numpy supplies nanmax and nanmin for the case where you want to ignore nans, and amax and amin for the case where a nan means something is wrong and you don't want to ignore the nan. (There are also nanargmax, nanargmin, and nansum.) > >> I think the strategy so far has been that inputs to plotting functions >> should use masked arrays, not nans, and correspondingly, the plotting >> functions should handle masked arrays gracefully. Although nans are >> used at some internal stages, I don't think they are handled correctly >> from end to end. We could add nan checks at the early argument >> processing stage, but it would slow things down a bit. > > Do you mean that matplotlib does not support input that contains nans? Should > the average user really have to care if they are passing input with nans in > it? I think not. I must have misunderstood. > I think that nans "do the right thing" in some places but not others; they have never been explicitly supported in plot function input. The design decision was to use masked arrays, which are more general, instead. I have thought about a possible alternative, in which masked arrays would be immediately converted to nan-filled arrays, and nans would be fully used and supported internally as well as in the interface. I never came to the conclusion that this was a good idea, though, because masked arrays have some advantages. Therefore I have been trying to improve masked array use and support in mpl and in numpy. Eric > Darren ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
