event.ind in point picking gives wrong number

Community matplotlib-users
1

I have Matplotlib 1.1.0, and am doing point picking (using the OO approach to Matplotlib, and embedded in wxPython). My relevant code is as follows:

#connect the pick event to the pick event handler:

self.cid = self.canvas.mpl_connect(‘pick_event’, self.on_pick)

#This is the relevant part of the pick event handler:

def on_pick(self, event):

if isinstance(event.artist, Line2D):

        ind = event.ind              
        print 'ind is: ', str(ind)

This had been working in some cases, but I’ve found a case in which it appears to be giving me a value for ind that doesn’t make sense. For example, I have a plot with two lines on it (and two y axes), each with over 50 points. When I pick one of the points right near the end, I expect the ind here will be about 50. However, it prints ind is: 3. In other words, the wrong index value. This is a serious issue for me, because I then use that index to look up information about that point.

What could be going on here?

Thanks,
Che

2

Just a follow-up on this problem…

I’ve found now that the index is only off if the plot is zoomed, and in the following way. When I zoom, the first point that is visible in the plot window will have index = 0, the next point will have index = 1, and so forth. If I zoom another section of the points, the indices are “reset” in this same way.

What’s really bizarre is that this is only occurring on one plot. When I try to reproduce the problem on other plots (so far at least), I can’t.

Any suggestions for how to chase this down would be very welcome.

Thanks.

···

On Sun, Sep 15, 2013 at 5:30 PM, C M <cmpython@…287…> wrote:

I have Matplotlib 1.1.0, and am doing point picking (using the OO approach to Matplotlib, and embedded in wxPython). My relevant code is as follows:

#connect the pick event to the pick event handler:

self.cid = self.canvas.mpl_connect(‘pick_event’, self.on_pick)

#This is the relevant part of the pick event handler:

def on_pick(self, event):

if isinstance(event.artist, Line2D):

        ind = event.ind              
        print 'ind is: ', str(ind)

This had been working in some cases, but I’ve found a case in which it appears to be giving me a value for ind that doesn’t make sense. For example, I have a plot with two lines on it (and two y axes), each with over 50 points. When I pick one of the points right near the end, I expect the ind here will be about 50. However, it prints ind is: 3. In other words, the wrong index value. This is a serious issue for me, because I then use that index to look up information about that point.

What could be going on here?

Thanks,
Che

3

That is a very useful observation. I am not very familiar with the artist
picking code, but if I have to guess, I would wonder if indices are being
determined from a path created *after* clip_to_rect() is used internally.
Given that you are having difficulties in reproducing this issue in other
plots, I would suggest trying to pare down your badly behaving code as much
as you can and post it here. Furthermore, it would also be useful to
determine if the issue still occurs in v1.3 or in the master branch.

Cheers!
Ben Root

···

On Sun, Sep 15, 2013 at 11:59 PM, C M <cmpython@...287...> wrote:

Just a follow-up on this problem...

I've found now that the index is only off if the plot is zoomed, and in
the following way. When I zoom, the first point that is visible in the
plot window will have index = 0, the next point will have index = 1, and so
forth. If I zoom another section of the points, the indices are "reset" in
this same way.

What's really bizarre is that this is only occurring on one plot. When I
try to reproduce the problem on other plots (so far at least), I can't.

Any suggestions for how to chase this down would be very welcome.

Thanks.

4

Hello again. This is follow-up on this 9 month old thread (I left this issue for a while and am now returning to it).

I upgraded to the latest stable version of Matplotlib, 1.3.1, and tested and I am still getting the exact same confusing problem.

Now I also have a small runnable test script that demonstrates this problem, from IDLE using Python 2.7 and Matplotlib 1.3.1.

Attached is the script. If you run it as is, it will show a plot. Click on the last point (which is obviously higher than the rest) and note the index number that is printed in the IDLE prompt. It should say “index is: [154]”. But now zoom the plot tightly around that last point, and click on it again. Now it will report that the index is much smaller (depending on how tightly you zoomed), down to “index is: [1]”. This is the problem.

What’s critical to point out is: this only occurs with this data. To show that, go to the script and comment out the line near the end that starts with “plt.plot(bad_final_dates,” and comment in the one below it, that starts with “plt.plot(good_final_dates,”. Run the script again, and repeat the process above. You’ll find that zooming does not affect the index number–which is the correct behavior.

The contains_points() function was something I got on this mailing list from Jae-Joon some years back, and it is above my level of understanding, and it’s possible I goofed something up in there.

I’m really puzzled why one set of data doesn’t have this problem and another one does. Any suggestions for what’s wrong greatly appreciated.

Thanks,

Che

zoom_causes_point_index_change_sample.py (10.1 KB)

···

On Mon, Sep 16, 2013 at 9:15 AM, Benjamin Root <ben.root@…1304…> wrote:

On Sun, Sep 15, 2013 at 11:59 PM, C M <cmpython@…120…287…> wrote:

Just a follow-up on this problem…

I’ve found now that the index is only off if the plot is zoomed, and in the following way. When I zoom, the first point that is visible in the plot window will have index = 0, the next point will have index = 1, and so forth. If I zoom another section of the points, the indices are “reset” in this same way.

What’s really bizarre is that this is only occurring on one plot. When I try to reproduce the problem on other plots (so far at least), I can’t.

Any suggestions for how to chase this down would be very welcome.

Thanks.

That is a very useful observation. I am not very familiar with the artist picking code, but if I have to guess, I would wonder if indices are being determined from a path created after clip_to_rect() is used internally. Given that you are having difficulties in reproducing this issue in other plots, I would suggest trying to pare down your badly behaving code as much as you can and post it here. Furthermore, it would also be useful to determine if the issue still occurs in v1.3 or in the master branch.

Cheers!
Ben Root

5

Thanks for the example script. I think I have a clue now what is happening.

If one were to also print out the length of the “d” array, you will find that it is significantly shorter than when you aren’t zoomed (I am getting a length of 7 when it should be 155). But it isn’t truncated for the other dataset (which is of length 62). This makes me suspect that there is some threshold being triggered here (possibly around 128?). I know there is such a threshold for Paths for path simplification, but my tests turning it off do not seem to make a difference. So, perhaps this might be related to clipping?

I think at this point, you should definitely file a bug report.

Cheers!

Ben Root

···

On Sat, Jun 7, 2014 at 3:19 PM, C M <cmpython@…287…> wrote:

Hello again. This is follow-up on this 9 month old thread (I left this issue for a while and am now returning to it).

I upgraded to the latest stable version of Matplotlib, 1.3.1, and tested and I am still getting the exact same confusing problem.

Now I also have a small runnable test script that demonstrates this problem, from IDLE using Python 2.7 and Matplotlib 1.3.1.

Attached is the script. If you run it as is, it will show a plot. Click on the last point (which is obviously higher than the rest) and note the index number that is printed in the IDLE prompt. It should say “index is: [154]”. But now zoom the plot tightly around that last point, and click on it again. Now it will report that the index is much smaller (depending on how tightly you zoomed), down to “index is: [1]”. This is the problem.

What’s critical to point out is: this only occurs with this data. To show that, go to the script and comment out the line near the end that starts with “plt.plot(bad_final_dates,” and comment in the one below it, that starts with “plt.plot(good_final_dates,”. Run the script again, and repeat the process above. You’ll find that zooming does not affect the index number–which is the correct behavior.

The contains_points() function was something I got on this mailing list from Jae-Joon some years back, and it is above my level of understanding, and it’s possible I goofed something up in there.

I’m really puzzled why one set of data doesn’t have this problem and another one does. Any suggestions for what’s wrong greatly appreciated.

Thanks,

Che

Learn Graph Databases - Download FREE O’Reilly Book

“Graph Databases” is the definitive new guide to graph databases and their

applications. Written by three acclaimed leaders in the field,

this first edition is now available. Download your free book today!

http://p.sf.net/sfu/NeoTech

Matplotlib-users mailing list

Matplotlib-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Mon, Sep 16, 2013 at 9:15 AM, Benjamin Root <ben.root@…1304…> wrote:

On Sun, Sep 15, 2013 at 11:59 PM, C M <cmpython@…287…> wrote:

Just a follow-up on this problem…

I’ve found now that the index is only off if the plot is zoomed, and in the following way. When I zoom, the first point that is visible in the plot window will have index = 0, the next point will have index = 1, and so forth. If I zoom another section of the points, the indices are “reset” in this same way.

What’s really bizarre is that this is only occurring on one plot. When I try to reproduce the problem on other plots (so far at least), I can’t.

Any suggestions for how to chase this down would be very welcome.

Thanks.

That is a very useful observation. I am not very familiar with the artist picking code, but if I have to guess, I would wonder if indices are being determined from a path created after clip_to_rect() is used internally. Given that you are having difficulties in reproducing this issue in other plots, I would suggest trying to pare down your badly behaving code as much as you can and post it here. Furthermore, it would also be useful to determine if the issue still occurs in v1.3 or in the master branch.

Cheers!
Ben Root

6

Thanks for the example script. I think I have a clue now what is happening.

Thank you for the quick reply.

If one were to also print out the length of the "d" array, you will find
that it is significantly shorter than when you aren't zoomed (I am getting
a length of 7 when it should be 155). But it isn't truncated for the other
dataset (which is of length 62). This makes me suspect that there is some
threshold being triggered here (possibly around 128?).

I've tested it, and it seems that threshold number is 100. If the dataset
has 100 points, the zooming doesn't affect the index. If it has 101 or
more (I guess...I didn't test it in any comprehensive way), I get the
error.

I think at this point, you should definitely file a bug report.

I have filed a bug report:

And I made it such that there is just the one data set and you can truncate
it to however many points you want, with the direction being to try 101
(which it is set to initially) and then try 100 or less.

Che

···

On Sat, Jun 7, 2014 at 4:02 PM, Benjamin Root <ben.root@...1304...> wrote: