Re: [Matplotlib-users] Exact semantics of ion()??

[Eric O LEBIGOT (EOL)]

I really appreciate your continuing this discussion, Ben.

Benjamin Root-2 wrote:
> 
> On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL) <
> eric.lebi...@normalesup.org> wrote:
> Question: would displaying a figure (or a group of figures), pausing to
> let
> you close them, and then continuing to the next figures more along the
> lines
> of what you want?  That is certainly possible with matplotlib.  Since
> v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
> for certain backends to do this correctly).
> 
Yeah, the new show() is nice.  However, I don't want my users to have to
close the numerous opened figures one by one, even if it is done in 4 times
3 clicks (and, again, it would not be convenient to put the graphs in
subplots).  So, what I am really looking for is really: (1) display figures
without having to use show(); and (2) do this efficiently (without automatic
drawing through the interactive mode).


Benjamin Root-2 wrote:
> 
> (…) In pyplot, nearly all
> drawing commands have as the final step a call to a function called
> "draw_if_interactive()".
> (…)
> You could call directly call
> draw() on each object you want re-drawn, but you don't have to.  You can
> give a single call to a parent object that would call draw() for all of
> its
> children objects.
> (…)
> 
Thank you for these more theoretical explanations, which are interesting.

However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
backend), or 1.0.0 Mac OS X (default backend and GTKAgg).  The main problem
is that draw() does unfortunately not draw anything in non-interactive mode
(this happens when there is no show() in the code)!  So, with these two
recent version, in *non*-interactive mode, it does not appear that "a
refresh does not occur until you tell it to with a call to draw()", and
things like this.  There is no refresh at all, and pyplot.draw() does
display anything (this is illustrated by the last program example I posted). 
As far as I can see, theory and practice strongly clash, about the
"refreshing" effect of the draw() command (in non-interactive mode), as I
can't see anything being refreshed or displayed by draw.  What is your take
on this?

Thank you for the idea of bypassing pyplot's automatic update in interactive
mode.  How is this done?  Doing ax.draw(ax.figure.canvas.renderer) raises a
RunTime error with the default Mac OS X backend, and an AttributeError with
the GTKAgg backend.  How should the draw() method of Matplotlib objects be
called?

Now that I'm thinking of it, the crux of the problem might be that
pyplot.figure() does *not* open any window, in non-interactive mode (until
show() is called, which I want to avoid).  This looks like a bad start if
draw() is to refresh anything…  Could this be the main stumbling block?  Can
a new window be opened in non-interactive mode (without using show())?
-- 
View this message in context: 
http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31738725.html
Sent from the matplotlib - users mailing list archive at Nabble.com.


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Exact semantics of ion()??

[Eric Firing]

On 05/30/2011 09:59 PM, Eric O LEBIGOT (EOL) wrote:


I really appreciate your continuing this discussion, Ben.

Benjamin Root-2 wrote:


On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL)<
eric.lebi...@normalesup.org>  wrote:
Question: would displaying a figure (or a group of figures), pausing to
let
you close them, and then continuing to the next figures more along the
lines
of what you want?  That is certainly possible with matplotlib.  Since
v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
for certain backends to do this correctly).


Yeah, the new show() is nice.  However, I don't want my users to have to
close the numerous opened figures one by one, even if it is done in 4 times
3 clicks (and, again, it would not be convenient to put the graphs in
subplots).  So, what I am really looking for is really: (1) display figures
without having to use show(); and (2) do this efficiently (without automatic
drawing through the interactive mode).


Benjamin Root-2 wrote:


(…) In pyplot, nearly all
drawing commands have as the final step a call to a function called
"draw_if_interactive()".
(…)
You could call directly call
draw() on each object you want re-drawn, but you don't have to.  You can
give a single call to a parent object that would call draw() for all of
its
children objects.
(…)


Thank you for these more theoretical explanations, which are interesting.

However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
backend), or 1.0.0 Mac OS X (default backend and GTKAgg).  The main problem
is that draw() does unfortunately not draw anything in non-interactive mode
(this happens when there is no show() in the code)!  So, with these two
recent version, in *non*-interactive mode, it does not appear that "a
refresh does not occur until you tell it to with a call to draw()", and
things like this.  There is no refresh at all, and pyplot.draw() does
display anything (this is illustrated by the last program example I posted).
As far as I can see, theory and practice strongly clash, about the
"refreshing" effect of the draw() command (in non-interactive mode), as I
can't see anything being refreshed or displayed by draw.  What is your take
on this?

Thank you for the idea of bypassing pyplot's automatic update in interactive
mode.  How is this done?  Doing ax.draw(ax.figure.canvas.renderer) raises a
RunTime error with the default Mac OS X backend, and an AttributeError with
the GTKAgg backend.  How should the draw() method of Matplotlib objects be
called?

Now that I'm thinking of it, the crux of the problem might be that
pyplot.figure() does *not* open any window, in non-interactive mode (until
show() is called, which I want to avoid).  This looks like a bad start if
draw() is to refresh anything…  Could this be the main stumbling block?  Can
a new window be opened in non-interactive mode (without using show())?


Stop saying you want to avoid show(); let's just figure out how to get 
to the desired end result.  You probably *need* to use show; with 1.0.1 
in interactive mode, it will not block.  Your script can close the 
windows; your user doesn't have to do so manually.


It sounds like you are indeed talking about a free-standing script, that 
is, not involving ipython or other intermediate shell, correct?


Can you come up with a minimal example of what you want it to do, and 
how you want the user to be able to interact with it?  Does the attached 
script illustrate something roughly like what you are trying to do?


Eric


#/usr/bin/env python

import matplotlib.pyplot as plt

fig = plt.figure()
ax = fig.add_subplot(1,1,1)
ax.plot([1,2,1.5])
ax.set_title("Try this")
plt.ion()
plt.show()

answer = raw_input("Was that OK?")
if answer == 'Y':
fig.close()
else:
fig2 = plt.figure()
ax2 = fig2.add_subplot(1,1,1)
ax2.plot([3,2,1.5])
ax2.set_title("second try")
plt.draw()

answer = raw_input("Add another line?")
if answer == 'Y':
ax2.plot([3.5, 2.5, 1.3], 'ro')
plt.draw()


answer = raw_input("Return to quit")



--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Exact semantics of ion()??

[Eric Firing]

One-line correction to script attached to last post; so use the one 
attached here.
#/usr/bin/env python

import matplotlib.pyplot as plt

fig = plt.figure()
ax = fig.add_subplot(1,1,1)
ax.plot([1,2,1.5])
ax.set_title("Try this")
plt.ion()
plt.show()

answer = raw_input("Was that OK?")
if answer == 'Y':
plt.close(fig)
else:
fig2 = plt.figure()
ax2 = fig2.add_subplot(1,1,1)
ax2.plot([3,2,1.5])
ax2.set_title("second try")
plt.draw()

answer = raw_input("Add another line?")
if answer == 'Y':
ax2.plot([3.5, 2.5, 1.3], 'ro')
plt.draw()


answer = raw_input("Return to quit")


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Exact semantics of ion()??

[Eric O LEBIGOT (EOL)]

efiring wrote:
> 
> Stop saying you want to avoid show(); (…).  You probably *need* to use
> show; with 1.0.1 
> in interactive mode, it will not block.  Your script can close the 
> windows; your user doesn't have to do so manually.
> 
You are right: your script shows that the latest (1.0.1) show() is great, as
it is non-blocking in interactive mode (except with the macosx backend). 
(It is the pre-1.0.1 blocking show() that was not a solution.)


efiring wrote:
> 
> It sounds like you are indeed talking about a free-standing script, that 
> is, not involving ipython or other intermediate shell, correct?
> 
Correct.


efiring wrote:
> 
> Does the attached 
> script illustrate something roughly like what you are trying to do?
> 
Yes, it does, thanks.  Just a detail: since the interactive mode is on, the
plt.draw()s in the second part are not necessary, are they?

So, to summarize, the latest 1.0.1 show() does the actual drawing (not
draw()), is non-blocking in interactive mode, and can be called multiple
times.  This is both convenient (no need to manually close umpteen windows
one by one), and efficient (non interactive mode can be used up until show()
is called).  Thus, the practical side of the problem is closed: thanks!

I have been asking these questions because I have been using and teaching
(Python and) Matplotlib for 3 years, now, to students who use a variety of
OSes, so I wanted to get things straight.

On the "theoretical" side, draw() is actually rarely used for drawing or
refreshing simple figures (including common non-animated figures), but is
more for "some more advanced features such as animations and widgets, as
well as for internal use.", as Ben was writing, right?  And show() is really
the function that commonly does the actual display or refresh, right?  If
this is correct, I will be done with my questions.
:-)

-- 
View this message in context: 
http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31739359.html
Sent from the matplotlib - users mailing list archive at Nabble.com.


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

[Matplotlib-users] Line clipping on subplot border mandatory?

[Lars Moeller]

Wonderful, thanks - that was far too easy to be 
thought of :)

Cheers,
Nix

On 05/30/2011 05:21 AM, Benjamin Root wrote:

> >  On Monday, May 30, 2011, Mondsuechtiger   wrote:
>> >>  -BEGIN PGP SIGNED MESSAGE-
>> >>  Hash: SHA1
>> >>
>> >>
>> >>  Hello,
>> >>
>> >>  I would like to stack subplots in a figure with a couple of basic
>> >>  x,y-line plots with the subplot frames removed.
>> >>  But possible overlap of subplots is limited, because the drawn data
>> >>  lines are clipped on the border, if you'd lets say manually reset the
>> >>  ylims and decrease it below the highest data y-values.
>> >>  I know it is possible with any kind of text or data annotation, but do
>> >>  not find a way to let the data lines cross the frame border.
You can cross the Axes frame border by turning off clipping:

ll = plot([-1, 1])[0]
axis([0.1, 0.95, -1, 1])
ll.set_clip_on(False)
draw()

Eric



>> >>
>> >>  I hope I made myself halfway clear - pls. don't hesitate to ask if not.
>> >>  Does one of you possibly have a solution or is it maybe plain
>> >>  impossible?
>> >>  Thanks!
>> >>
>> >>  Cheers,
>> >>  Nix
> >
> >  Maybe you want to use matplotlib's spine feature?  You are right that
> >  you can't plot outside the plotable region, but maybe you can emulate
> >  what you want by moving the axes lines into the plottable region.
> >
> >  I hope that helps!
> >
> >  Ben Root
> >



--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

[Matplotlib-users] ginput() mouse button assignment

[jgrub]

Hello,

im currently working on data analysis with matplotlib
and have some problems with the useage of the mousebuttons when using the
ginput() function 

i actually have a long sequence of data on which i want to achiece 4  linear
regressions,
so my idea was to plot the data and choose the data points  with help of
ginput(8) so i can choose 8 points between which the data gets evaluated the
problem is the big size of data so i have to zoom in and out between
choosing 2 points.

my problem is that the ginput function interprets the zoom in clicks as
choosing a point from my data,
i already tried to override the left mouse button to the ride button but it
seems to me that it is online 
possible to switch the button configuration so that i have the mouse_pop
function on the left mouse button and the mouse_pop function on the right
side, but this doesnt help me either since each data point gets erased when
i zoom in 

thanks for your help so far

-- 
View this message in context: 
http://old.nabble.com/ginput%28%29-mouse--button-assignment-tp31735320p31735320.html
Sent from the matplotlib - users mailing list archive at Nabble.com.


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

[Matplotlib-users] import pylab - macosx 10.6

[Jo]

Hi Matplotlib Users,

First of all, I hope this is the right place to ask my questions, otherwise, 
apologies for the spam.

I am trying to install python on my mac (10.6.7) and I have some issues when 
trying to import pylab. 
I installed python 2.7.1 from the EDP package (32-bit), I have numpy 1.5.0 and 
matplotlib 1.0.0.
I can import both numpy and matplotlib successfully (backend is MacOSX, I also 
tried TkAgg).

But no matter how I try to import pylab ("import pylab", "from pylab import *", 
"ipython -pylab", "from matplotlib import pylab") I always have the following 
message:

> >>> import pylab
> Traceback (most recent call last):
>   File "", line 1, in 
>   File 
> "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/pylab.py",
>  line 1, in 
> from matplotlib.pylab import *
>   File 
> "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/pylab.py",
>  line 216, in 
> from matplotlib import mpl  # pulls in most modules
>   File 
> "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/mpl.py",
>  line 2, in 
> from matplotlib import axis
>   File 
> "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/axis.py",
>  line 10, in 
> import matplotlib.font_manager as font_manager
>   File 
> "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/font_manager.py",
>  line 52, in 
> from matplotlib import ft2font
> ImportError: 
> dlopen(/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/ft2font.so,
>  2): Library not loaded: @rpath/libfreetype.6.dylib
>   Referenced from: 
> /Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/ft2font.so
>   Reason: image not found

Just to be sure, a "which python" returns:

> /Library/Frameworks/Python.framework/Versions/7.0/bin/python



I also checked that I do have the "ft2font.so" file inside 
/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/.

To me it seems that the library "libfreetype.6.dylib" cannot be found, but I 
must confess I have no idea what this @rpath is. Of course, I already tried to 
google this but couldn't find a proper solution. A "locate libfreetype.6.dylib" 
returns the following:

> /Applications/TeX/TeXworks.app/Contents/Frameworks/libfreetype.6.dylib
> /Applications/VLC.app/Contents/MacOS/lib/libfreetype.6.dylib
> /Developer/SDKs/MacOSX10.5.sdk/usr/X11/lib/libfreetype.6.dylib
> /Developer/SDKs/MacOSX10.6.sdk/usr/X11/lib/libfreetype.6.dylib
> /Library/Frameworks/Python.framework/Versions/7.0/lib/libfreetype.6.dylib
> /usr/X11/lib/libfreetype.6.dylib

Using the otool -L to see the different links of the last two files here's what 
I have:

> >otool -L 
> >/Library/Frameworks/Python.framework/Versions/7.0/lib/libfreetype.6.dylib
> /Library/Frameworks/Python.framework/Versions/7.0/lib/libfreetype.6.dylib:
>   @rpath/libfreetype.6.dylib (compatibility version 13.0.0, current 
> version 13.2.0)
>   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
> 1.2.3)
>   /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 
> 1.0.0)
>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
> version 111.0.0)


> >otool -L /usr/X11/lib/libfreetype.6.dylib
> /usr/X11/lib/libfreetype.6.dylib:
>   /usr/X11/lib/libfreetype.6.dylib (compatibility version 13.0.0, current 
> version 13.0.0)
>   /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 
> 1.2.3)
>   
> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices 
> (compatibility version 1.0.0, current version 44.0.0)
>   
> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
>  (compatibility version 1.0.0, current version 38.0.0)
>   /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
> version 125.2.1)
>   
> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 
> (compatibility version 150.0.0, current version 550.34.0)

And then, I'm completely lost and I have no idea how to proceed. Anyone has an 
idea how to solve this ?
Thanks a lot,

Johan


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

[Matplotlib-users] Input array dimensions for contour or contourf

[Mannucci, Anthony J (335G)]

The following program seems to work with contour/contourf. However the 
documentation for the contourf function states

contour(X,Y,Z)

"X, Y, and Z must be arrays with the same dimensions."

I am finding that contour works if the dimension of X and Y are 1, but Z must 
be two-dimensional. The following program seems to bear this out. Are the 
arrays x and y below two-dimensional, or is the documentation misleading? 
Thanks for your help.

import numpy as N
import pylab as PLT

lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
lats = N.linspace(-3.,3.,4)

z = N.zeros((len(lats), len(lons)))
for i in range(len(lons)):
for j in range(len(lats)):
z[j,i]=i+j

PLT.clf()
PLT.contourf(lons,lats,z)
PLT.colorbar()
PLT.show()

-Tony

--
Tony Mannucci
Supervisor, Ionospheric and Atmospheric Remote Sensing Group
 Mail-Stop 138-308, Tel > (818) 354-1699
 Jet Propulsion Laboratory,  Fax > (818) 393-5115
 California Institute of Technology, Email > 
tony.mannu...@jpl.nasa.gov
 4800 Oak Grove Drive,   http://genesis.jpl.nasa.gov
 Pasadena, CA 91109

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Benjamin Root]

On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G) <
anthony.j.mannu...@jpl.nasa.gov> wrote:

> The following program seems to work with contour/contourf. However the
> documentation for the contourf function states
>
> contour(X,Y,Z)
>
> "*X*, *Y*, and *Z* must be arrays with the same dimensions."
>
> I am finding that contour works if the dimension of X and Y are 1, but Z
> must be two-dimensional. The following program seems to bear this out. Are
> the arrays x and y below two-dimensional, or is the documentation
> misleading? Thanks for your help.
>
> import numpy as N
> import pylab as PLT
>
> lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
> lats = N.linspace(-3.,3.,4)
>
> z = N.zeros((len(lats), len(lons)))
> for i in range(len(lons)):
> for j in range(len(lats)):
> z[j,i]=i+j
>
> PLT.clf()
> PLT.contourf(lons,lats,z)
> PLT.colorbar()
> PLT.show()
>
> -Tony
>
>
Tony,

contour and contourf seems to take advantage of numpy's broadcasting
feature, so it is probably more correct to say that X and Y must be at least
broadcastable to the shape of Z.  I think there are a number of functions
where this may or may not be true, and at some point we (the developers)
should agree on basic input array handling and make it consistent across all
plotting functions.

So, technically speaking, the docs are "right", but should be clearer in
this case.  I will add it to my doc-fixing commit that I will do today.

Ben Root
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Exact semantics of ion()??

[Eric Firing]

On 05/30/2011 11:42 PM, Eric O LEBIGOT (EOL) wrote:
>
>
> efiring wrote:
>>
>> Stop saying you want to avoid show(); (…).  You probably *need* to use
>> show; with 1.0.1

The above was wrong--see below.  If you start with interactive mode on, 
you do not need show at all.  In non-interactive mode, you do need show.

>> in interactive mode, it will not block.  Your script can close the
>> windows; your user doesn't have to do so manually.
>>
> You are right: your script shows that the latest (1.0.1) show() is great, as
> it is non-blocking in interactive mode (except with the macosx backend).
> (It is the pre-1.0.1 blocking show() that was not a solution.)
>
>
> efiring wrote:
>>
>> It sounds like you are indeed talking about a free-standing script, that
>> is, not involving ipython or other intermediate shell, correct?
>>
> Correct.
>
>
> efiring wrote:
>>
>> Does the attached
>> script illustrate something roughly like what you are trying to do?
>>
> Yes, it does, thanks.  Just a detail: since the interactive mode is on, the
> plt.draw()s in the second part are not necessary, are they?

Not a detail: you do need the draw if you are not ending with a pyplot 
function, as opposed to an object method.  You could just use the pyplot 
function, plt.plot(), instead of the method, ax.plot(), etc., which 
would call the draw automatically.

Now, you may find that everything works the same if you eliminate the 
first draw in my example; that is because the plt.figure() call has put 
a draw request in to the gui toolkit, and the toolkit is not executing 
it right away.  Don't rely on this, however; if you are using the object 
methods, call draw when you want the figure to be refreshed.

>
> So, to summarize, the latest 1.0.1 show() does the actual drawing (not
> draw()), is non-blocking in interactive mode, and can be called multiple
> times.  This is both convenient (no need to manually close umpteen windows
> one by one), and efficient (non interactive mode can be used up until show()
> is called).  Thus, the practical side of the problem is closed: thanks!

Not quite. Draw() ensures that everything is up to date; show() is not a 
direct substitute.

In my example script, I should have put the call to plt.ion() *before* 
all other pyplot calls. If you do that, then you actually don't need the 
show() at all, because the the initial call to plt.figure() in 
interactive mode displays the figure.


>
> I have been asking these questions because I have been using and teaching
> (Python and) Matplotlib for 3 years, now, to students who use a variety of
> OSes, so I wanted to get things straight.
>
> On the "theoretical" side, draw() is actually rarely used for drawing or
> refreshing simple figures (including common non-animated figures), but is
> more for "some more advanced features such as animations and widgets, as
> well as for internal use.", as Ben was writing, right?  And show() is really
> the function that commonly does the actual display or refresh, right?  If
> this is correct, I will be done with my questions.
> :-)
>

No, if you use object methods rather than the pyplot interface, then you 
need to use draw().  For example, if you try changing the last draw() in 
my example to a show(), the new line will not be added.

Eric


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Eric Firing]

On 05/31/2011 05:50 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>  > wrote:
>
> The following program seems to work with contour/contourf. However
> the documentation for the contourf function states
>
> contour(X,Y,Z)
>
> "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>
> I am finding that contour works if the dimension of X and Y are 1,
> but Z must be two-dimensional. The following program seems to bear
> this out. Are the arrays x and y below two-dimensional, or is the
> documentation misleading? Thanks for your help.
>
> import numpy as N
> import pylab as PLT
>
> lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
> lats = N.linspace(-3.,3.,4)
>
> z = N.zeros((len(lats), len(lons)))
> for i in range(len(lons)):
>  for j in range(len(lats)):
>  z[j,i]=i+j
>
> PLT.clf()
> PLT.contourf(lons,lats,z)
> PLT.colorbar()
> PLT.show()
>
> -Tony
>
>
> Tony,
>
> contour and contourf seems to take advantage of numpy's broadcasting
> feature, so it is probably more correct to say that X and Y must be at
> least broadcastable to the shape of Z.  I think there are a number of

Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions, 
which must then match Z. Broadcasting is not used or supported. So, the 
contour docstring was not updated when this functionality was added, 
long ago.  Consider it an undocumented feature, in need of documentation.

Eric


> functions where this may or may not be true, and at some point we (the
> developers) should agree on basic input array handling and make it
> consistent across all plotting functions.
>
> So, technically speaking, the docs are "right", but should be clearer in
> this case.  I will add it to my doc-fixing commit that I will do today.
>
> Ben Root
>
>
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
>
>
>
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Benjamin Root]

On Tue, May 31, 2011 at 12:58 PM, Eric Firing  wrote:

> On 05/31/2011 05:50 AM, Benjamin Root wrote:
> >
> >
> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
> >  > > wrote:
> >
> > The following program seems to work with contour/contourf. However
> > the documentation for the contourf function states
> >
> > contour(X,Y,Z)
> >
> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
> >
> > I am finding that contour works if the dimension of X and Y are 1,
> > but Z must be two-dimensional. The following program seems to bear
> > this out. Are the arrays x and y below two-dimensional, or is the
> > documentation misleading? Thanks for your help.
> >
> > import numpy as N
> > import pylab as PLT
> >
> > lons = N.linspace(-5.,5.,5) # Is this a one or two dimensional array?
> > lats = N.linspace(-3.,3.,4)
> >
> > z = N.zeros((len(lats), len(lons)))
> > for i in range(len(lons)):
> >  for j in range(len(lats)):
> >  z[j,i]=i+j
> >
> > PLT.clf()
> > PLT.contourf(lons,lats,z)
> > PLT.colorbar()
> > PLT.show()
> >
> > -Tony
> >
> >
> > Tony,
> >
> > contour and contourf seems to take advantage of numpy's broadcasting
> > feature, so it is probably more correct to say that X and Y must be at
> > least broadcastable to the shape of Z.  I think there are a number of
>
> Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions,
> which must then match Z. Broadcasting is not used or supported. So, the
> contour docstring was not updated when this functionality was added,
> long ago.  Consider it an undocumented feature, in need of documentation.
>
> Eric
>
>
Well, (as a bit of a cop-out) in my edit, I didn't say that they were
broadcasted, only that they must be broadcastable to the same shape.  Would
that suffice, or should I re-word that?

Ben Root
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Eric Firing]

On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 12:58 PM, Eric Firing  > wrote:
>
> On 05/31/2011 05:50 AM, Benjamin Root wrote:
>  >
>  >
>  > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>  >  
>  >  >> wrote:
>  >
>  > The following program seems to work with contour/contourf.
> However
>  > the documentation for the contourf function states
>  >
>  > contour(X,Y,Z)
>  >
>  > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>  >
>  > I am finding that contour works if the dimension of X and Y
> are 1,
>  > but Z must be two-dimensional. The following program seems to
> bear
>  > this out. Are the arrays x and y below two-dimensional, or is the
>  > documentation misleading? Thanks for your help.
>  >
>  > import numpy as N
>  > import pylab as PLT
>  >
>  > lons = N.linspace(-5.,5.,5) # Is this a one or two
> dimensional array?
>  > lats = N.linspace(-3.,3.,4)
>  >
>  > z = N.zeros((len(lats), len(lons)))
>  > for i in range(len(lons)):
>  >  for j in range(len(lats)):
>  >  z[j,i]=i+j
>  >
>  > PLT.clf()
>  > PLT.contourf(lons,lats,z)
>  > PLT.colorbar()
>  > PLT.show()
>  >
>  > -Tony
>  >
>  >
>  > Tony,
>  >
>  > contour and contourf seems to take advantage of numpy's broadcasting
>  > feature, so it is probably more correct to say that X and Y must
> be at
>  > least broadcastable to the shape of Z.  I think there are a number of
>
> Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions,
> which must then match Z. Broadcasting is not used or supported. So, the
> contour docstring was not updated when this functionality was added,
> long ago.  Consider it an undocumented feature, in need of
> documentation.
>
> Eric
>
>
> Well, (as a bit of a cop-out) in my edit, I didn't say that they were
> broadcasted, only that they must be broadcastable to the same shape.
> Would that suffice, or should I re-word that?

It would not be correct.

x and y must both be 2-D, with the same shape as z; or they must both be 
1-D such that len(x) is the number of columns in z and len(y) is the 
number of rows.

Eric

>
> Ben Root
>


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

[Matplotlib-users] Matplotlib hi

[zane . selvans]

Matplotlib you won't be disappointed 
http://g.msn.com.br/BR9/1369.0?http://cnbc7.com/news

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Benjamin Root]

On Tue, May 31, 2011 at 1:28 PM, Eric Firing  wrote:

> On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>>
>>
>> On Tue, May 31, 2011 at 12:58 PM, Eric Firing > > wrote:
>>
>>On 05/31/2011 05:50 AM, Benjamin Root wrote:
>> >
>> >
>> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>> > >
>> > >>> wrote:
>> >
>> > The following program seems to work with contour/contourf.
>>However
>> > the documentation for the contourf function states
>> >
>> > contour(X,Y,Z)
>> >
>> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>> >
>> > I am finding that contour works if the dimension of X and Y
>>are 1,
>> > but Z must be two-dimensional. The following program seems to
>>bear
>> > this out. Are the arrays x and y below two-dimensional, or is
>> the
>> > documentation misleading? Thanks for your help.
>> >
>> > import numpy as N
>> > import pylab as PLT
>> >
>> > lons = N.linspace(-5.,5.,5) # Is this a one or two
>>dimensional array?
>> > lats = N.linspace(-3.,3.,4)
>> >
>> > z = N.zeros((len(lats), len(lons)))
>> > for i in range(len(lons)):
>> >  for j in range(len(lats)):
>> >  z[j,i]=i+j
>> >
>> > PLT.clf()
>> > PLT.contourf(lons,lats,z)
>> > PLT.colorbar()
>> > PLT.show()
>> >
>> > -Tony
>> >
>> >
>> > Tony,
>> >
>> > contour and contourf seems to take advantage of numpy's broadcasting
>> > feature, so it is probably more correct to say that X and Y must
>>be at
>> > least broadcastable to the shape of Z.  I think there are a number
>> of
>>
>>Not quite; if x and y are 1-D, meshgrid is called to make 2-D versions,
>>which must then match Z. Broadcasting is not used or supported. So, the
>>contour docstring was not updated when this functionality was added,
>>long ago.  Consider it an undocumented feature, in need of
>>documentation.
>>
>>Eric
>>
>>
>> Well, (as a bit of a cop-out) in my edit, I didn't say that they were
>> broadcasted, only that they must be broadcastable to the same shape.
>> Would that suffice, or should I re-word that?
>>
>
> It would not be correct.
>
> x and y must both be 2-D, with the same shape as z; or they must both be
> 1-D such that len(x) is the number of columns in z and len(y) is the number
> of rows.
>
> Eric
>
>
Gotcha, I didn't think about the mixed 1-D and 2-D case.

In addition, is the note in the contour doc about masked arrays still valid,
or can this be removed/updated?

"*Z* may be a masked array, but filled contouring may not handle internal
masked regions correctly."

Ben Root
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Eric Firing]

On 05/31/2011 08:37 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 1:28 PM, Eric Firing  > wrote:
>
> On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>
>
> On Tue, May 31, 2011 at 12:58 PM, Eric Firing
> mailto:efir...@hawaii.edu>
> >> wrote:
>
> On 05/31/2011 05:50 AM, Benjamin Root wrote:
>  >
>  >
>  > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>  >  
>  >
>  >  
>    >
>  > The following program seems to work with contour/contourf.
> However
>  > the documentation for the contourf function states
>  >
>  > contour(X,Y,Z)
>  >
>  > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>  >
>  > I am finding that contour works if the dimension of X and Y
> are 1,
>  > but Z must be two-dimensional. The following program seems to
> bear
>  > this out. Are the arrays x and y below two-dimensional,
> or is the
>  > documentation misleading? Thanks for your help.
>  >
>  > import numpy as N
>  > import pylab as PLT
>  >
>  > lons = N.linspace(-5.,5.,5) # Is this a one or two
> dimensional array?
>  > lats = N.linspace(-3.,3.,4)
>  >
>  > z = N.zeros((len(lats), len(lons)))
>  > for i in range(len(lons)):
>  >  for j in range(len(lats)):
>  >  z[j,i]=i+j
>  >
>  > PLT.clf()
>  > PLT.contourf(lons,lats,z)
>  > PLT.colorbar()
>  > PLT.show()
>  >
>  > -Tony
>  >
>  >
>  > Tony,
>  >
>  > contour and contourf seems to take advantage of numpy's
> broadcasting
>  > feature, so it is probably more correct to say that X and Y must
> be at
>  > least broadcastable to the shape of Z.  I think there are a
> number of
>
> Not quite; if x and y are 1-D, meshgrid is called to make
> 2-D versions,
> which must then match Z. Broadcasting is not used or
> supported. So, the
> contour docstring was not updated when this functionality
> was added,
> long ago.  Consider it an undocumented feature, in need of
> documentation.
>
> Eric
>
>
> Well, (as a bit of a cop-out) in my edit, I didn't say that they
> were
> broadcasted, only that they must be broadcastable to the same shape.
> Would that suffice, or should I re-word that?
>
>
> It would not be correct.
>
> x and y must both be 2-D, with the same shape as z; or they must
> both be 1-D such that len(x) is the number of columns in z and
> len(y) is the number of rows.
>
> Eric
>
>
> Gotcha, I didn't think about the mixed 1-D and 2-D case.
>
> In addition, is the note in the contour doc about masked arrays still
> valid, or can this be removed/updated?
>
> "*Z* may be a masked array, but filled contouring may not handle
> internal masked regions correctly."

Good catch.  Ian Thomas fixed the contouring algorithm so that it 
handles masked regions perfectly.

Eric

>
> Ben Root
>


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Benjamin Root]

On Tue, May 31, 2011 at 2:38 PM, Eric Firing  wrote:

> On 05/31/2011 08:37 AM, Benjamin Root wrote:
>
>>
>>
>> On Tue, May 31, 2011 at 1:28 PM, Eric Firing > > wrote:
>>
>>On 05/31/2011 08:03 AM, Benjamin Root wrote:
>>
>>
>>
>>On Tue, May 31, 2011 at 12:58 PM, Eric Firing
>>mailto:efir...@hawaii.edu>
>>>> wrote:
>>
>>On 05/31/2011 05:50 AM, Benjamin Root wrote:
>> >
>> >
>> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>> > >
>>>>
>> > >
>>>> >
>> > The following program seems to work with contour/contourf.
>>However
>> > the documentation for the contourf function states
>> >
>> > contour(X,Y,Z)
>> >
>> > "/X/, /Y/, and /Z/ must be arrays with the same dimensions."
>> >
>> > I am finding that contour works if the dimension of X and Y
>>are 1,
>> > but Z must be two-dimensional. The following program seems
>> to
>>bear
>> > this out. Are the arrays x and y below two-dimensional,
>>or is the
>> > documentation misleading? Thanks for your help.
>> >
>> > import numpy as N
>> > import pylab as PLT
>> >
>> > lons = N.linspace(-5.,5.,5) # Is this a one or two
>>dimensional array?
>> > lats = N.linspace(-3.,3.,4)
>> >
>> > z = N.zeros((len(lats), len(lons)))
>> > for i in range(len(lons)):
>> >  for j in range(len(lats)):
>> >  z[j,i]=i+j
>> >
>> > PLT.clf()
>> > PLT.contourf(lons,lats,z)
>> > PLT.colorbar()
>> > PLT.show()
>> >
>> > -Tony
>> >
>> >
>> > Tony,
>> >
>> > contour and contourf seems to take advantage of numpy's
>>broadcasting
>> > feature, so it is probably more correct to say that X and Y must
>>be at
>> > least broadcastable to the shape of Z.  I think there are a
>>number of
>>
>>Not quite; if x and y are 1-D, meshgrid is called to make
>>2-D versions,
>>which must then match Z. Broadcasting is not used or
>>supported. So, the
>>contour docstring was not updated when this functionality
>>was added,
>>long ago.  Consider it an undocumented feature, in need of
>>documentation.
>>
>>Eric
>>
>>
>>Well, (as a bit of a cop-out) in my edit, I didn't say that they
>>were
>>broadcasted, only that they must be broadcastable to the same
>> shape.
>>Would that suffice, or should I re-word that?
>>
>>
>>It would not be correct.
>>
>>x and y must both be 2-D, with the same shape as z; or they must
>>both be 1-D such that len(x) is the number of columns in z and
>>len(y) is the number of rows.
>>
>>Eric
>>
>>
>> Gotcha, I didn't think about the mixed 1-D and 2-D case.
>>
>> In addition, is the note in the contour doc about masked arrays still
>> valid, or can this be removed/updated?
>>
>> "*Z* may be a masked array, but filled contouring may not handle
>> internal masked regions correctly."
>>
>
> Good catch.  Ian Thomas fixed the contouring algorithm so that it handles
> masked regions perfectly.
>
> Eric
>
>
When did that happen?  I can make it a "versionadded" note so that users of
older versions won't be confused.

Ben Root
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] Input array dimensions for contour or contourf

[Eric Firing]

>
>
> Good catch.  Ian Thomas fixed the contouring algorithm so that it
> handles masked regions perfectly.
>
> Eric
>
>
> When did that happen?  I can make it a "versionadded" note so that users
> of older versions won't be confused.

It was about 15 months ago.  I think it is better to just delete any 
reference to the problem.

Eric

>
> Ben Root
>


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

[Matplotlib-users] eps and useTex: tick labels drawn over legend box

[Brannon]

Hi,

I am having trouble with matplotlib 1.0.1 drawing the axis tick labels over
the legend box in the eps output when useTex is set to true. The plot shown
after calling plt.show() looks fine, as does the output in pdf, png, svg
etc. Only the postscript appears to be affected.

The following simple example produces the png and eps files given at the
bottom of this post:

import matplotlib as mpl
import matplotlib.pyplot as plt
from matplotlib import rc

rc('text', usetex=True)

g1 = plt.plot([1,2,3,4],[500,600,700,800])
g2 = plt.plot([1,2,3,4],[700,300,700,200])
g3 = plt.plot([1,2,3,4],[800,600,900,800])

plt.figlegend([g1,g2,g3],['test1','test2','test3'],'upper left')

plt.savefig('image.png')
plt.savefig('image.eps')

plt.show()

http://old.nabble.com/file/p31744864/image.eps image.eps 
http://old.nabble.com/file/p31744864/image.png image.png 

I would very much appreciate some help resolving this issue.

Thanks
-- 
View this message in context: 
http://old.nabble.com/eps-and-useTex%3A-tick-labels-drawn-over-legend-box-tp31744864p31744864.html
Sent from the matplotlib - users mailing list archive at Nabble.com.


--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] bug in mpl_toolkits.axes_grid1.AxesGrid?

[Jae-Joon Lee]

Using AxesGrid does not mean that color scales are shared. It only
takes care of axes placement. And it is your responsibility to sync
colorbars of multiple images.

One option is to use *norm* attribute of images.

   norm = matplotlib.colors.Normalize()

   for i in range(3):
   im = grid[i].imshow(Z, extent=extent, interpolation="nearest",
   norm=norm)
   im = grid[3].imshow(1000 * Z, extent=extent, interpolation="nearest",
   norm=norm)

Regards,

-JJ


On Wed, May 25, 2011 at 11:05 AM, Paul Anton Letnes
 wrote:
> Hi!
>
> I am wondering if there is a bug in:
> mpl_toolkits.axes_grid1.AxesGrid
>
> I am trying to run this example (I am of course working on something else, 
> but I am trying to build a minimal example of my problem):
> http://matplotlib.sourceforge.net/examples/axes_grid/demo_axes_grid.html
> This would be a very compact and nice way of showing my results, and I am 
> beginning to love it. There is one thing, though. Given the code attached at 
> the end of this message, the two versions produce figures that look 
> identical. To my mind, however, it doesn't exactly seem that the colorbars 
> are "shared" in any real sense.
>
> Try commenting out the 2-3 lines marked # Version 1 and # Version 2. I attach 
> two plots of what I get: same-looking plots with wildly varying colorbar 
> numbers. I'd like to get the numbers to be the same.
>
> TL;DR: In version 1 I am scaling the data for one of the contour plots by a 
> factor 1000, and would expect that plot to look quite different from the 
> others.
>
> Cheers
> Paul.
>
>
> # CODE:
> import matplotlib
> matplotlib.use('agg')
> import matplotlib.pyplot as plt
> from mpl_toolkits.axes_grid1 import AxesGrid
>
>
> def get_demo_image():
>    import numpy as np
>    from matplotlib.cbook import get_sample_data
>    f = get_sample_data("axes_grid/bivariate_normal.npy", asfileobj=False)
>    z = np.load(f)
>    # z is a numpy array of 15x15
>    return z, (-3,4,-4,3)
>
> def demo_grid_with_single_cbar(fig):
>    """
>    A grid of 2x2 images with a single colobar
>    """
>    grid = AxesGrid(fig, 132, # similar to subplot(132)
>                    nrows_ncols = (2, 2),
>                    axes_pad = 0.0,
>                    share_all=True,
>                    label_mode = "L",
>                    cbar_location = "top",
>                    cbar_mode="single")
>
>    Z, extent = get_demo_image()
>
>    # Version 1
>    #for i in range(3):
>        #im = grid[i].imshow(Z, extent=extent, interpolation="nearest")
>    #im = grid[3].imshow(1000 * Z, extent=extent, interpolation="nearest")
>    # Version 2
>    for i in range(4):
>        im = grid[i].imshow(Z, extent=extent, interpolation="nearest")
>
>    # The rest is the same
>    grid.cbar_axes[0].colorbar(im)
>
>    # This affects all axes as share_all = True.
>    grid.axes_llc.set_xticks([-2, 0, 2])
>    grid.axes_llc.set_yticks([-2, 0, 2])
>
>
> if 1:
>    F = plt.figure(1, (5.5, 2.5))
>
>    F.subplots_adjust(left=0.05, right=0.98)
>
>    demo_grid_with_single_cbar(F)
>
>    plt.savefig('cbars')
>    #plt.draw()
>    #plt.show()
>
>
> --
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] eps and useTex: tick labels drawn over legend box

[Jae-Joon Lee]

I'm not 100% sure on this but it seems that this is a limitation of
"psfrag" that the ps backend relies on. The ps backend first produces
an eps file without TeX labels, and these TeX labels are put on the
eps file with latex+psfrag. And it seems  these TeX labels are always
above the contents of the eps file.

Unfortunately, I don't think this can be easily fixed.
Regards,

-JJ


On Wed, Jun 1, 2011 at 6:34 AM, Brannon  wrote:
>
> Hi,
>
> I am having trouble with matplotlib 1.0.1 drawing the axis tick labels over
> the legend box in the eps output when useTex is set to true. The plot shown
> after calling plt.show() looks fine, as does the output in pdf, png, svg
> etc. Only the postscript appears to be affected.
>
> The following simple example produces the png and eps files given at the
> bottom of this post:
>
> import matplotlib as mpl
> import matplotlib.pyplot as plt
> from matplotlib import rc
>
> rc('text', usetex=True)
>
> g1 = plt.plot([1,2,3,4],[500,600,700,800])
> g2 = plt.plot([1,2,3,4],[700,300,700,200])
> g3 = plt.plot([1,2,3,4],[800,600,900,800])
>
> plt.figlegend([g1,g2,g3],['test1','test2','test3'],'upper left')
>
> plt.savefig('image.png')
> plt.savefig('image.eps')
>
> plt.show()
>
> http://old.nabble.com/file/p31744864/image.eps image.eps
> http://old.nabble.com/file/p31744864/image.png image.png
>
> I would very much appreciate some help resolving this issue.
>
> Thanks
> --
> View this message in context: 
> http://old.nabble.com/eps-and-useTex%3A-tick-labels-drawn-over-legend-box-tp31744864p31744864.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> --
> Simplify data backup and recovery for your virtual environment with vRanger.
> Installation's a snap, and flexible recovery options mean your data is safe,
> secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev
> ___
> Matplotlib-users mailing list
> Matplotlib-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Re: [Matplotlib-users] eps and useTex: tick labels drawn over legend box

[Jae-Joon Lee]

Just in case, I have opened a git issue on this.

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

-JJ



On Wed, Jun 1, 2011 at 1:23 PM, Jae-Joon Lee  wrote:
> I'm not 100% sure on this but it seems that this is a limitation of
> "psfrag" that the ps backend relies on. The ps backend first produces
> an eps file without TeX labels, and these TeX labels are put on the
> eps file with latex+psfrag. And it seems  these TeX labels are always
> above the contents of the eps file.
>
> Unfortunately, I don't think this can be easily fixed.
> Regards,
>
> -JJ
>
>
> On Wed, Jun 1, 2011 at 6:34 AM, Brannon  wrote:
>>
>> Hi,
>>
>> I am having trouble with matplotlib 1.0.1 drawing the axis tick labels over
>> the legend box in the eps output when useTex is set to true. The plot shown
>> after calling plt.show() looks fine, as does the output in pdf, png, svg
>> etc. Only the postscript appears to be affected.
>>
>> The following simple example produces the png and eps files given at the
>> bottom of this post:
>>
>> import matplotlib as mpl
>> import matplotlib.pyplot as plt
>> from matplotlib import rc
>>
>> rc('text', usetex=True)
>>
>> g1 = plt.plot([1,2,3,4],[500,600,700,800])
>> g2 = plt.plot([1,2,3,4],[700,300,700,200])
>> g3 = plt.plot([1,2,3,4],[800,600,900,800])
>>
>> plt.figlegend([g1,g2,g3],['test1','test2','test3'],'upper left')
>>
>> plt.savefig('image.png')
>> plt.savefig('image.eps')
>>
>> plt.show()
>>
>> http://old.nabble.com/file/p31744864/image.eps image.eps
>> http://old.nabble.com/file/p31744864/image.png image.png
>>
>> I would very much appreciate some help resolving this issue.
>>
>> Thanks
>> --
>> View this message in context: 
>> http://old.nabble.com/eps-and-useTex%3A-tick-labels-drawn-over-legend-box-tp31744864p31744864.html
>> Sent from the matplotlib - users mailing list archive at Nabble.com.
>>
>>
>> --
>> Simplify data backup and recovery for your virtual environment with vRanger.
>> Installation's a snap, and flexible recovery options mean your data is safe,
>> secure and there when you need it. Data protection magic?
>> Nope - It's vRanger. Get your free trial download today.
>> http://p.sf.net/sfu/quest-sfdev2dev
>> ___
>> Matplotlib-users mailing list
>> Matplotlib-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users