matplotlib-users Mailing List for matplotlib (Page 4)

Great, thanks for all the help!
On Sun, Jun 8, 2014 at 12:09 AM, Eric Firing <ef...@ha...> wrote:
> On 2014年06月07日, 5:03 PM, C M wrote:
> >
> >
> >
> > On Sat, Jun 7, 2014 at 10:18 PM, Eric Firing <ef...@ha...
> > <mailto:ef...@ha...>> wrote:
> >
> > On 2014年06月07日, 4:12 PM, C M wrote:
> > > I had been using a custom function (written originally by
> > Jae-Joon and
> > > modified a little by me...quite a long time back now) that was
> > working
> > > to allow point picking of markers, but *not* the line connecting
> > them.
> > > However, I've now discovered with the help of this list that the
> > > function I am using has the disadvantage that if there are more
> > than 100
> > > data points, I can't get the correct index for the picked marker
> > (turned
> > > out not to be a mpl bug:
> > > https://github.com/matplotlib/matplotlib/issues/3124).
> > >
> > > So I can just use the default pick event, but then the user can
> pick
> > > anywhere on the connecting line, which is meaningless in this
> > use--so I
> > > don't want them to be able to pick on the connecting line.
> >
> > Why not just execute plot twice, once with the markers, with picking
> > activated, and a second time with the line, with picking inactive
> (the
> > default).
> >
> > Eric
> >
> >
> > That is so simple, and I hadn't thought of it at all. Thank you! My
> > only concerns would be for slowness of plotting if there are a lot of
> > points and just code simplicity, and so if there could be some other way
> > with a custom function for the picker that would do this, I would
> > probably prefer that. But maybe neither of these are particularly
> > important concerns.
>
> I think you will find plotting two lines instead of one is not at all
> prohibitive with respect to speed; especially when you are zooming, so
> that the number of points being plotted is not so large.
>
> As for simplicity, two calls to a standard function with almost the same
> arguments beats an arcane special-purpose function!
>
> If you want to make your own picker, though, it looks like you could use
> a slight modification of Line2D.contains(); it would be just a matter of
> copying it and replacing this section
>
> # Check for collision
> if self._linestyle in ['None', None]:
> # If no line, return the nearby point(s)
> d = (xt - mouseevent.x) ** 2 + (yt - mouseevent.y) ** 2
> ind, = np.nonzero(np.less_equal(d, pixels ** 2))
> else:
> # If line, return the nearby segment(s)
> ind = segment_hits(mouseevent.x, mouseevent.y, xt, yt,
> pixels)
>
>
> with the code in the first option--that is, without checking the
> _linestyle. You would also need to remove the first two lines after the
> docstring.
>
> Eric
>
> >
> > 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
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>
>
>
> ------------------------------------------------------------------------------
> 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
>

On 2014年06月07日, 5:03 PM, C M wrote:
>
>
>
> On Sat, Jun 7, 2014 at 10:18 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 2014年06月07日, 4:12 PM, C M wrote:
> > I had been using a custom function (written originally by
> Jae-Joon and
> > modified a little by me...quite a long time back now) that was
> working
> > to allow point picking of markers, but *not* the line connecting
> them.
> > However, I've now discovered with the help of this list that the
> > function I am using has the disadvantage that if there are more
> than 100
> > data points, I can't get the correct index for the picked marker
> (turned
> > out not to be a mpl bug:
> > https://github.com/matplotlib/matplotlib/issues/3124).
> >
> > So I can just use the default pick event, but then the user can pick
> > anywhere on the connecting line, which is meaningless in this
> use--so I
> > don't want them to be able to pick on the connecting line.
>
> Why not just execute plot twice, once with the markers, with picking
> activated, and a second time with the line, with picking inactive (the
> default).
>
> Eric
>
>
> That is so simple, and I hadn't thought of it at all. Thank you! My
> only concerns would be for slowness of plotting if there are a lot of
> points and just code simplicity, and so if there could be some other way
> with a custom function for the picker that would do this, I would
> probably prefer that. But maybe neither of these are particularly
> important concerns.
I think you will find plotting two lines instead of one is not at all 
prohibitive with respect to speed; especially when you are zooming, so 
that the number of points being plotted is not so large.
As for simplicity, two calls to a standard function with almost the same 
arguments beats an arcane special-purpose function!
If you want to make your own picker, though, it looks like you could use 
a slight modification of Line2D.contains(); it would be just a matter of 
copying it and replacing this section
 # Check for collision
 if self._linestyle in ['None', None]:
 # If no line, return the nearby point(s)
 d = (xt - mouseevent.x) ** 2 + (yt - mouseevent.y) ** 2
 ind, = np.nonzero(np.less_equal(d, pixels ** 2))
 else:
 # If line, return the nearby segment(s)
 ind = segment_hits(mouseevent.x, mouseevent.y, xt, yt, 
pixels)
with the code in the first option--that is, without checking the 
_linestyle. You would also need to remove the first two lines after the 
docstring.
Eric
>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Sat, Jun 7, 2014 at 10:18 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年06月07日, 4:12 PM, C M wrote:
> > I had been using a custom function (written originally by Jae-Joon and
> > modified a little by me...quite a long time back now) that was working
> > to allow point picking of markers, but *not* the line connecting them.
> > However, I've now discovered with the help of this list that the
> > function I am using has the disadvantage that if there are more than 100
> > data points, I can't get the correct index for the picked marker (turned
> > out not to be a mpl bug:
> > https://github.com/matplotlib/matplotlib/issues/3124).
> >
> > So I can just use the default pick event, but then the user can pick
> > anywhere on the connecting line, which is meaningless in this use--so I
> > don't want them to be able to pick on the connecting line.
>
> Why not just execute plot twice, once with the markers, with picking
> activated, and a second time with the line, with picking inactive (the
> default).
>
> Eric
>
That is so simple, and I hadn't thought of it at all. Thank you! My only
concerns would be for slowness of plotting if there are a lot of points and
just code simplicity, and so if there could be some other way with a custom
function for the picker that would do this, I would probably prefer that.
But maybe neither of these are particularly important concerns.
Che

On 2014年06月07日, 4:12 PM, C M wrote:
> I had been using a custom function (written originally by Jae-Joon and
> modified a little by me...quite a long time back now) that was working
> to allow point picking of markers, but *not* the line connecting them.
> However, I've now discovered with the help of this list that the
> function I am using has the disadvantage that if there are more than 100
> data points, I can't get the correct index for the picked marker (turned
> out not to be a mpl bug:
> https://github.com/matplotlib/matplotlib/issues/3124).
>
> So I can just use the default pick event, but then the user can pick
> anywhere on the connecting line, which is meaningless in this use--so I
> don't want them to be able to pick on the connecting line.
Why not just execute plot twice, once with the markers, with picking 
activated, and a second time with the line, with picking inactive (the 
default).
Eric
>
> My goal is to have a custom function that will serve *both* purposes:
> allow picking the markers only, not the line, of a set of data of any
> length while returning the correct index of that marker/data point. But
> the code in the custom function is mostly above my head, was written for
> mpl 0.99 or so, and I don't know how to modify it to get both purposes
> achieved.
>
> I attach the current sample again, with the problematic custom picker
> function, "contains_points()". Thanks for any suggestions or help.
>
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I had been using a custom function (written originally by Jae-Joon and
modified a little by me...quite a long time back now) that was working to
allow point picking of markers, but *not* the line connecting them.
However, I've now discovered with the help of this list that the function I
am using has the disadvantage that if there are more than 100 data points,
I can't get the correct index for the picked marker (turned out not to be a
mpl bug: https://github.com/matplotlib/matplotlib/issues/3124).
So I can just use the default pick event, but then the user can pick
anywhere on the connecting line, which is meaningless in this use--so I
don't want them to be able to pick on the connecting line.
My goal is to have a custom function that will serve *both* purposes:
allow picking the markers only, not the line, of a set of data of any
length while returning the correct index of that marker/data point. But
the code in the custom function is mostly above my head, was written for
mpl 0.99 or so, and I don't know how to modify it to get both purposes
achieved.
I attach the current sample again, with the problematic custom picker
function, "contains_points()". Thanks for any suggestions or help.
Che

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
>

Jorge Scandaliaris <jorgesmbox-ml@...> writes:
> 
> Hi,
> I just mentioned this problem with Qt4Agg and python 3.4 in another thread
> [1], but I decided to post it on a thread of its own, as I suspect it might
> be a bug in the Qt4Agg backend.
> 
> I get a NameError exception (see backtrace below) when trying to use key
> events in matplotlib (master branch rev:
> e322d5f5bb024bbec44d3ba76da1bc16bf52af9c), python 3.4.1, and pyqt 4.10.
> Is this a bug?
> 
A trivial fix using six (credits to Werner for suggesting it), also
submitted as issue #3117 in the GH tracker:
diff --git a/lib/matplotlib/backends/backend_qt4.py
b/lib/matplotlib/backends/backend_qt4.py
index 70152aa..26486b4 100644
--- a/lib/matplotlib/backends/backend_qt4.py
+++ b/lib/matplotlib/backends/backend_qt4.py
@@ -362,7 +362,7 @@ class FigureCanvasQT(QtGui.QWidget, FigureCanvasBase):
 if event_key > MAX_UNICODE:
 return None
- key = unichr(event_key)
+ key = six.unichr(event_key)
 # qt delivers capitalized letters. fix capitalization
 # note that capslock is ignored
 if 'shift' in mods:

On 6/5/2014 15:45, "V. Armando Solé" wrote:
...
>> You would use 'six' - https://pypi.python.org/pypi/six it is used by
>> many packages including wxPython.
>>
>> import six
>>
>> if six.PY3:
>> 	key = chr(event_key)
>>
>> else:
>> 	key = unichr(event_key)
>>
> Just for info.
>
> I had never heard about six. Is there anything wrong using sys???:
>
> import sys
> if sys.version < "3.0":
> key = unichr(event_key)
> else:
> key = chr(event_key)
>
> Thanks,
Using 'six' for just the above case is definitely overkill, but it has 
many more goodies in it to make py2/py3 single source code easier.
Werner

On 05/06/2014 15:24, Werner wrote:
> On 6/5/2014 15:10, Jorge Scandaliaris wrote:
>> Jorge Scandaliaris <jorgesmbox-ml@...> writes:
>>
>>> Hi,
>>> I just mentioned this problem with Qt4Agg and python 3.4 in another thread
>>> [1], but I decided to post it on a thread of its own, as I suspect it might
>>> be a bug in the Qt4Agg backend.
>>>
>>> I get a NameError exception (see backtrace below) when trying to use key
>>> events in matplotlib (master branch rev:
>>> e322d5f5bb024bbec44d3ba76da1bc16bf52af9c), python 3.4.1, and pyqt 4.10.
>>> Is this a bug?
>> I can confirm that using chr() instead of unichr() fixes this problem. I
>> don't know how ones handle python2 vs python3 in these cases
>>
>> diff --git a/lib/matplotlib/backends/backend_qt4.py
>> b/lib/matplotlib/backends/backend_qt4.py
>> index 70152aa..b0d8233 100644
>> --- a/lib/matplotlib/backends/backend_qt4.py
>> +++ b/lib/matplotlib/backends/backend_qt4.py
>> @@ -362,7 +362,7 @@ class FigureCanvasQT(QtGui.QWidget, FigureCanvasBase):
>> if event_key > MAX_UNICODE:
>> return None
>> 
>> - key = unichr(event_key)
>> + key = chr(event_key)
>> # qt delivers capitalized letters. fix capitalization
>> # note that capslock is ignored
>> if 'shift' in mods:
> You would use 'six' - https://pypi.python.org/pypi/six it is used by
> many packages including wxPython.
>
> import six
>
> if six.PY3:
> 	key = chr(event_key)
>
> else:
> 	key = unichr(event_key)
>
Just for info.
I had never heard about six. Is there anything wrong using sys???:
import sys
if sys.version < "3.0":
 key = unichr(event_key)
else:
 key = chr(event_key)
Thanks,
Armando

On 6/5/2014 15:10, Jorge Scandaliaris wrote:
> Jorge Scandaliaris <jorgesmbox-ml@...> writes:
>
>> Hi,
>> I just mentioned this problem with Qt4Agg and python 3.4 in another thread
>> [1], but I decided to post it on a thread of its own, as I suspect it might
>> be a bug in the Qt4Agg backend.
>>
>> I get a NameError exception (see backtrace below) when trying to use key
>> events in matplotlib (master branch rev:
>> e322d5f5bb024bbec44d3ba76da1bc16bf52af9c), python 3.4.1, and pyqt 4.10.
>> Is this a bug?
> I can confirm that using chr() instead of unichr() fixes this problem. I
> don't know how ones handle python2 vs python3 in these cases
>
> diff --git a/lib/matplotlib/backends/backend_qt4.py
> b/lib/matplotlib/backends/backend_qt4.py
> index 70152aa..b0d8233 100644
> --- a/lib/matplotlib/backends/backend_qt4.py
> +++ b/lib/matplotlib/backends/backend_qt4.py
> @@ -362,7 +362,7 @@ class FigureCanvasQT(QtGui.QWidget, FigureCanvasBase):
> if event_key > MAX_UNICODE:
> return None
> 
> - key = unichr(event_key)
> + key = chr(event_key)
> # qt delivers capitalized letters. fix capitalization
> # note that capslock is ignored
> if 'shift' in mods:
You would use 'six' - https://pypi.python.org/pypi/six it is used by 
many packages including wxPython.
import six
if six.PY3:
	key = chr(event_key)
else:
	key = unichr(event_key)
Werner

Jorge Scandaliaris <jorgesmbox-ml@...> writes:
> 
> Hi,
> I just mentioned this problem with Qt4Agg and python 3.4 in another thread
> [1], but I decided to post it on a thread of its own, as I suspect it might
> be a bug in the Qt4Agg backend.
> 
> I get a NameError exception (see backtrace below) when trying to use key
> events in matplotlib (master branch rev:
> e322d5f5bb024bbec44d3ba76da1bc16bf52af9c), python 3.4.1, and pyqt 4.10.
> Is this a bug?
I can confirm that using chr() instead of unichr() fixes this problem. I
don't know how ones handle python2 vs python3 in these cases
diff --git a/lib/matplotlib/backends/backend_qt4.py
b/lib/matplotlib/backends/backend_qt4.py
index 70152aa..b0d8233 100644
--- a/lib/matplotlib/backends/backend_qt4.py
+++ b/lib/matplotlib/backends/backend_qt4.py
@@ -362,7 +362,7 @@ class FigureCanvasQT(QtGui.QWidget, FigureCanvasBase):
 if event_key > MAX_UNICODE:
 return None
 
- key = unichr(event_key)
+ key = chr(event_key)
 # qt delivers capitalized letters. fix capitalization
 # note that capslock is ignored
 if 'shift' in mods:
jorge

Werner <wernerfbd@...> writes:
<...>
> Some time ago I did a bit of work on the wx backend to work with 
> wxPython Phoenix.
> 
> https://github.com/matplotlib/matplotlib/pull/2803
> 
> I haven't had time to look at the last few comments made on that PR.
> 
> Just the other day someone contacted me off list and he used it on a 
> project of his with a recent build of Phoenix. He noted small refresh 
> issues which corrected itself by resizing the frame, this probably needs 
> a "self.Refresh" or similar when things get drawn.
> 
> Builds for Phoenix are here:
> http://wxpython.org/Phoenix/snapshot-builds/
> 
> Recent versions of Phoenix (this is still in development) run on Py 2.7, 
> Py 3.3 and Py 3.4 and use the wheel format and can be installed with the 
> following at least on Windows and Mac as far as I know:
> 
> pip install -U --pre -f http://wxpython.org/Phoenix/snapshot-builds/ 
> wxPython_Phoenix
> 
> Werner
> 
> 
Thanks for the info, but at this point I'd rather focus on the task I need
to solve rather than in the necessary tools. I have just creted a new thread
regarding the Qt4Agg backend problem I saw, as that is probably the closest
path to have a working setup. If that can't be solved, I have to probably go
back to python 2. I upgraded in the first place because it seemed like all
the tools were ready, and that's a natural path, but I can live with python
2 for a bit longer...
Jorge

Hi,
I just mentioned this problem with Qt4Agg and python 3.4 in another thread
[1], but I decided to post it on a thread of its own, as I suspect it might
be a bug in the Qt4Agg backend.
I get a NameError exception (see backtrace below) when trying to use key
events in matplotlib (master branch rev:
e322d5f5bb024bbec44d3ba76da1bc16bf52af9c), python 3.4.1, and pyqt 4.10.
Is this a bug?
Regards,
Jorge
backtrace:
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
/home/jscandal/sw/matplotlib/matplotlib/lib/matplotlib/backends/backend_qt4.py
in
keyReleaseEvent(self=<matplotlib.backends.backend_qt4agg.FigureCanvasQTAgg
object>, event=<PyQt4.QtGui.QKeyEvent object>)
 308 
 309 def keyReleaseEvent(self, event):
--> 310 key = self._get_key(event)
 key = undefined
 self._get_key = <bound method FigureCanvasQTAgg._get_key of
<matplotlib.backends.backend_qt4agg.FigureCanvasQTAgg object at 0x7f0393412948>>
 event = <PyQt4.QtGui.QKeyEvent object at 0x7f0393507a68>
 311 if key is None:
 312 return
/home/jscandal/sw/matplotlib/matplotlib/lib/matplotlib/backends/backend_qt4.py
in _get_key(self=<matplotlib.backends.backend_qt4agg.FigureCanvasQTAgg
object>, event=<PyQt4.QtGui.QKeyEvent object>)
 363 return None
 364 
--> 365 key = unichr(event_key)
 key = undefined
 global unichr = undefined
 global event_key = undefined
 366 # qt delivers capitalized letters. fix capitalization
 367 # note that capslock is ignored
NameError: name 'unichr' is not defined
[1] http://thread.gmane.org/gmane.comp.python.matplotlib.general/34361

Hi Jorge,
Oops, sorry for first sending it directly to your mail.
Some time ago I did a bit of work on the wx backend to work with 
wxPython Phoenix.
https://github.com/matplotlib/matplotlib/pull/2803
I haven't had time to look at the last few comments made on that PR.
Just the other day someone contacted me off list and he used it on a 
project of his with a recent build of Phoenix. He noted small refresh 
issues which corrected itself by resizing the frame, this probably needs 
a "self.Refresh" or similar when things get drawn.
Builds for Phoenix are here:
http://wxpython.org/Phoenix/snapshot-builds/
Recent versions of Phoenix (this is still in development) run on Py 2.7, 
Py 3.3 and Py 3.4 and use the wheel format and can be installed with the 
following at least on Windows and Mac as far as I know:
pip install -U --pre -f http://wxpython.org/Phoenix/snapshot-builds/ 
wxPython_Phoenix
Werner

On 05/06/2014 07:21, Jorge Scandaliaris wrote:
> Hi,
> After a while away from matplotlib I am back working on some old code. I
> decided to switch to python 3 (bad idea?) and I am having problems with
> backends. I used to use GTKAgg, it worked ok, but it doesn't seem to work
> with python 3?
> 1- What are my choices running python 3 and matplotlib from source (I
> started following the master branch to avoid some bugs in the past, and kept
> using it since)? I did look in the docs and searched the lists, but I
> couldn't find a clear answer.
> 2- Is it discouraged to use matplotlib with python 3?
I am using matplotlib with Python 3 and the Qt backend (PyQt4 and 
PySide) but I did not try to handle key events (just mouse) ...
Armando

Hi,
After a while away from matplotlib I am back working on some old code. I
decided to switch to python 3 (bad idea?) and I am having problems with
backends. I used to use GTKAgg, it worked ok, but it doesn't seem to work
with python 3?
1- What are my choices running python 3 and matplotlib from source (I
started following the master branch to avoid some bugs in the past, and kept
using it since)? I did look in the docs and searched the lists, but I
couldn't find a clear answer.
2- Is it discouraged to use matplotlib with python 3?
3- I got the Qt4Agg backend sort of working. It displays my figures ok, but
throws exceptions related to some key events I have set up. See below for
backtrace. unichr() has disappeared in python 3, but somehow the backend is
still using it?
Sorry about the post becoming a bit messy. 
Jorge
backtrace:
NameError Traceback (most recent call last)
/home/jscandal/sw/matplotlib/matplotlib/lib/matplotlib/backends/backend_qt4.py
in
keyReleaseEvent(self=<matplotlib.backends.backend_qt4agg.FigureCanvasQTAgg
object>, event=<PyQt4.QtGui.QKeyEvent object>)
 308 
 309 def keyReleaseEvent(self, event):
--> 310 key = self._get_key(event)
 key = undefined
 self._get_key = <bound method FigureCanvasQTAgg._get_key of
<matplotlib.backends.backend_qt4agg.FigureCanvasQTAgg object at 0x7fc124046af8>>
 event = <PyQt4.QtGui.QKeyEvent object at 0x7fc1260cfb88>
 311 if key is None:
 312 return
/home/jscandal/sw/matplotlib/matplotlib/lib/matplotlib/backends/backend_qt4.py
in _get_key(self=<matplotlib.backends.backend_qt4agg.FigureCanvasQTAgg
object>, event=<PyQt4.QtGui.QKeyEvent object>)
 363 return None
 364 
--> 365 key = unichr(event_key)
 key = undefined
 global unichr = undefined
 global event_key = undefined
 366 # qt delivers capitalized letters. fix capitalization
 367 # note that capslock is ignored
NameError: name 'unichr' is not defined

Dear all,
It is still the same problem. Actually my code like below :
import os
import netCDF4 as nc
import numpy as np
import matplotlib.pylab as pl
base_dir = 'C:/DATA2011/' # Note PC
nc_file1 = '20110301.faifb1p16m2.nc' # Single beam data
nc_file2 = '20110301.faifb1p16m3.nc' # Single beam data
nc_file3 = '20110301.faifb1p16m4.nc' # Single beam data
# Change directory
os.chdir(base_dir)
# Open netCDF file
fd1 = nc.Dataset(nc_file1, 'r')
fd2 = nc.Dataset(nc_file2, 'r')
fd3 = nc.Dataset(nc_file3, 'r')
# Read variables from the netCDF file
date1 = fd1.variables['date'][:]
beam1 = fd1.variables['beam'][:]
az1 = fd1.variables['az'][:]
ze1 = fd1.variables['ze'][:]
rng1 = fd1.variables['range'][:]
tim1 = fd1.variables['time'][:]
pwr1 = fd1.variables['pwr'][:]
dpl1 = fd1.variables['dpl'][:]
nfft1 = fd1.variables['nfft'][0]
pn1 = fd1.variables['pnoise'][:]
# Read variables from the netCDF file
date2 = fd2.variables['date'][:]
beam2 = fd2.variables['beam'][:]
az2 = fd2.variables['az'][:]
ze2 = fd2.variables['ze'][:]
rng2 = fd2.variables['range'][:]
tim2 = fd2.variables['time'][:]
pwr2 = fd2.variables['pwr'][:]
dpl2 = fd2.variables['dpl'][:]
nfft2 = fd2.variables['nfft'][0]
pn2 = fd2.variables['pnoise'][:]
# Read variables from the netCDF file
date3 = fd3.variables['date'][:]
beam3 = fd3.variables['beam'][:]
az3 = fd3.variables['az'][:]
ze3 = fd3.variables['ze'][:]
rng3 = fd3.variables['range'][:]
tim3 = fd3.variables['time'][:]
pwr3 = fd3.variables['pwr'][:]
dpl3 = fd3.variables['dpl'][:]
nfft3 = fd3.variables['nfft'][0]
pn3 = fd3.variables['pnoise'][:]
# Close netCDF file
fd1.close()
fd2.close()
fd3.close()
# Speify which beam to show
ibeam1 = 0
ibeam2 = 0
ibeam3 = 0
# Time convertion from seconds to hours
tim1 = tim1/3600.0
tim2 = tim2/3600.0
tim3 = tim3/3600.0
# Select data of the specified beam, and transpose
p_plot1 = pwr1[ibeam1]
for it1 in range(len(tim1)):
 p_plot1[it1] = p_plot1[it1] - pn1[ibeam1][it1] - 10.*np.log10(nfft1)
p_plot1 = p_plot1.transpose() 
# Select data of the specified beam, and transpose
p_plot2 = pwr2[ibeam2]
for it2 in range(len(tim2)):
 p_plot2[it2] = p_plot2[it2] - pn2[ibeam2][it2] - 10.*np.log10(nfft2)
p_plot2 = p_plot2.transpose() 
# Select data of the specified beam, and transpose
p_plot3 = pwr3[ibeam3]
for it3 in range(len(tim3)):
 p_plot3[it3] = p_plot3[it3] - pn3[ibeam3][it3] - 10.*np.log10(nfft3)
p_plot3 = p_plot3.transpose() 
# Count max SNR (single beam)
pthres1 = 2.0
N_total1 = 0
N_signal1 = 0
for j in range(len(tim1)):
 if 18.0 <= tim1[j] <= 30.0:
 for i in range(len(rng1)):
 N_total1 = N_total1 + 1
 if 200.0 <= rng1[i] <= 550 :
 if p_plot1[i][j] > pthres1:
 ipthres1 = i
 jpthres1 = j
 N_signal1 = N_signal1 + 1
 
# Count max SNR (single beam)
pthres2 = 2.0
N_total2 = 0
N_signal2 = 0
for j in range(len(tim2)):
 if 18.0 <= tim2[j] <= 30.0:
 for i in range(len(rng2)):
 N_total2 = N_total2 + 1
 if 200.0 <= rng2[i] <= 550 :
 if p_plot2[i][j] > pthres2:
 ipthres2 = i
 jpthres2 = j
 N_signal2 = N_signal2 + 1
 
# Count max SNR (single beam)
pthres3 = 2.0
N_total3 = 0
N_signal3 = 0
for j in range(len(tim3)):
 if 18.0 <= tim3[j] <= 30.0:
 for i in range(len(rng3)):
 N_total3 = N_total3 + 1
 if 200.0 <= rng3[i] <= 550 :
 if p_plot3[i][j] > pthres3:
 ipthres3 = i
 jpthres3 = j
 N_signal3 = N_signal3 + 1
 
fig = pl.figure()
#Plot contour
axs1=fig.add_subplot(3,1,1)
v1 = np.linspace(0., 50., 10., endpoint=True)
axs1=pl.contourf(tim1, rng1, p_plot1, v1, cmap1=pl.cm.jet)
x1 = pl.colorbar(ticks=v1)
print x1
# Set X and Y axis lower/upper limit
set_xy1 = range(4)
set_xy1[0] = 18.0 # x min
set_xy1[1] = 30.0 # x max
set_xy1[2] = 200.0 # y min
set_xy1[3] = 550.0 # y max
pl.axis(set_xy1)
axs2=fig.add_subplot(3,1,2)
v2 = np.linspace(0., 50., 10., endpoint=True)
axs2=pl.contourf(tim2, rng2, p_plot2, v2, cmap2=pl.cm.jet)
x2 = pl.colorbar(ticks=v2)
print x2
# Set X and Y axis lower/upper limit
set_xy2 = range(4)
set_xy2[0] = 18.0 # x min
set_xy2[1] = 30.0 # x max
set_xy2[2] = 200.0 # y min
set_xy2[3] = 550.0 # y max
pl.axis(set_xy2)
axs3=fig.add_subplot(3,1,3)
v3 = np.linspace(0., 50., 10., endpoint=True)
axs3=pl.contourf(tim3, rng3, p_plot3, v3, cmap3=pl.cm.jet)
x3 = pl.colorbar(ticks=v3)
print x3
# Set X and Y axis lower/upper limit
set_xy3 = range(4)
set_xy3[0] = 18.0 # x min
set_xy3[1] = 30.0 # x max
set_xy3[2] = 200.0 # y min
set_xy3[3] = 550.0 # y max
pl.axis(set_xy3)
pl.show()
# Set X and Y axis lower/upper limit
set_xy1 = range(4)
set_xy1[0] = 18.0 # x min
set_xy1[1] = 30.0 # x max
set_xy1[2] = 200.0 # y min
set_xy1[3] = 550.0 # y max
pl.axis(set_xy1)
Could somebody help me to make the code shorter by using loop and the image
only show one colorbar for three image?.
Recent result :
<http://matplotlib.1069221.n5.nabble.com/file/n43464/figure_1.png> 
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/One-colorbar-for-many-plot-tp43430p43464.html
Sent from the matplotlib - users mailing list archive at Nabble.com.