matplotlib-users Mailing List for matplotlib

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

> 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:

https://github.com/matplotlib/matplotlib/issues/3124

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

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 <cmp...@gm...> 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
>
>
> On Mon, Sep 16, 2013 at 9:15 AM, Benjamin Root <ben...@ou...> wrote:
>
>>
>>
>>
>> On Sun, Sep 15, 2013 at 11:59 PM, C M <cmp...@gm...> 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
>>
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

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


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

>
>
>
> On Sun, Sep 15, 2013 at 11:59 PM, C M <cmp...@gm...> 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
>