plotting array with inf

Community matplotlib-users
1

I have a question about plotting an array with an inf.

For example:

y = np.array([2.,1.,0,1.,2.])
y = 1.0 / y

So y is array([ 0.5, 1. , Inf, 1. , 0.5])

When I plot this, I get an error, of which the last line is:

OverflowError: math range error

I presume the problem is using the autoscale or something like that to set the data limits.

But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.

I know, I know, I can do this with masked arrays, but it cannot be that hard to make this work correctly, and wouldn’t that be much nicer? Desirable?

Mark

2

The question is: what should happen with inf? Do you know what matlab does?

JDH

···

On Tue, Aug 5, 2008 at 3:46 PM, Mark Bakker <markbak@...287...> wrote:

But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.

I know, I know, I can do this with masked arrays, but it cannot be that hard
to make this work correctly, and wouldn't that be much nicer? Desirable?

3

John Hunter wrote:

But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.

I know, I know, I can do this with masked arrays, but it cannot be that hard
to make this work correctly, and wouldn't that be much nicer? Desirable?

The question is: what should happen with inf? Do you know what matlab does?

Matlab ignores it, same as with a nan.

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.

Eric

···

On Tue, Aug 5, 2008 at 3:46 PM, Mark Bakker <markbak@...287...> wrote:

JDH

-------------------------------------------------------------------------
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
matplotlib-users List Signup and Options

4

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?

JDH

···

On Tue, Aug 5, 2008 at 7:03 PM, Eric Firing <efiring@...202...> wrote:

5

John Hunter wrote:

···

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?

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

6

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 <efiring@…202…> wrote:

John Hunter wrote:

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?

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

7

gnuplot also ignores them.
(I am not arguing this is the correct behavior;
just providing a data point.)

Cheers,
Alan Isaac

···

On Tue, 5 Aug 2008, John Hunter apparently wrote:

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.

8

Eric Firing wrote:

John Hunter wrote:
  

But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.

I know, I know, I can do this with masked arrays, but it cannot be that hard
to make this work correctly, and wouldn't that be much nicer? Desirable?
      

The question is: what should happen with inf? Do you know what matlab does?
    
Matlab ignores it, same as with a nan.

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 definitely was faster at the time I implemented it (particularly as the arrays get larger). The difference is that masked arrays must be handled in Python, and converted to regular arrays before passing on to the Agg backend by performing a compress (which implies a memcpy) and inserting MOVETO codes in the appropriate place. (I don't know if the new masked arrays have a C API we could use -- the old ones apparently didn't.)

With the Agg backend, NaNs are all handled in C code -- the iterator over the array just skips over them, so there's no memory copy. (The other backends still use Python, so the difference is probably a wash.)

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.
  

As long as we can do the equivalent in C, that seems fine. _path.cpp's get_path_extents is probably the most important place to be updated -- it currently doesn't even support NaNs. And then, of course, we'll need to update the "isnan" stuff in agg_py_path_iterator.h

Cheers,
Mike

···

On Tue, Aug 5, 2008 at 3:46 PM, Mark Bakker <markbak@...287...> wrote:

--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

9

They don't. I thought about it before, but decided to forget about it until I
could find a job where I could learn C and focus exclusively on that for a
few months. Unlikely anytime soon.

···

On Wednesday 06 August 2008 09:24:18 Michael Droettboom wrote:

  (I don't know if the
new masked arrays have a C API we could use -- the old ones apparently
didn't.)