On Tue, Aug 5, 2008 at 7:03 PM, Eric Firing <efiring@…202…> wrote:
Matlab ignores it, same as with a nan.
Although intuitively I think of inf as very different from nan, my
default is to go with matlab like behavior in the absence of
compelling a argument otherwise. I won’t be providing that argument
for isnan/inf, so if someone wants mpl to behave differently, step up
and argue why.
This needs a bit of thought and checking. Mike went to some trouble, I
believe, to make nans work without running everything through masked
arrays–whether this is actually faster than doing an initial masking
operation when needed and then using masked arrays everywhere internally
when bad values are present, I don’t know. It is possible that everything
could be made to work with infs simply by changing all “isnan(x)” to
“~isfinite(x)”, which has the advantage of being slightly faster
(surprisingly) as well as more general.
Perhaps we should centralize this functionality to a cbook analogue of
“is_string_like” or “iterable” called “is_plottable” or something to
that effect. That way, people writing plotting functions will not
have to decide if the inclusion criteria is isnan or ~isinfinite, but
instead can simply rely on the cbook function (with a moderate
performance hit for the extra function call). We will likely need a
version for a single axis (x or y) as well as for points ( (x,y)
tuples) – these ideally will support scalar or array inputs, or we
can provide array versions of each. There are only a few modules
using isnan currently (axes, contour, mlab and path) so it would not
be too difficult to centralize this functionality. Do you want to
take the lead on this one, Eric?