Thanks for stepping up to the plate, Eric.
I was asleep on this side of the ocean, so I didn't join in the discussion.
>From a functionality point of view, it seems to be a good idea to me not to
plot nans (that would actually be impossible) and not to plot infs. The
latter are indeed different than nans, but they are the same in that we
cannot plot them. And it will shield the pylab user from having to use
masked arrrays when it is not really necessary.
Eric - you think this will also work for contour, or do we have to keep
using masked arrays there? If this works for contouring, what will you do
with -inf and +inf in contourf?
Thanks, Mark
On Wed, Aug 6, 2008 at 5:54 AM, Eric Firing <[EMAIL PROTECTED]> wrote:
> John Hunter wrote:
>
>> On Tue, Aug 5, 2008 at 7:03 PM, Eric Firing <[EMAIL PROTECTED]> 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?
>>
>
> Yes, but I think that the cbook approach is overkill in this case, and
> counterproductive. Maybe I should add a bit to the coding guide, but we
> really don't need another wrapper just to handle nans and infs.
>
> I think I see how to fix everything, and improve speed, with only a few
> changes, including a couple in src.
>
> Eric
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
