matplotlib-users Mailing List for matplotlib

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.

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

On Tue, May 31, 2011 at 2:38 PM, Eric Firing <ef...@ha...> wrote:

> On 05/31/2011 08:37 AM, Benjamin Root wrote:
>
>>
>>
>> On Tue, May 31, 2011 at 1:28 PM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>>    On 05/31/2011 08:03 AM, Benjamin Root wrote:
>>
>>
>>
>>        On Tue, May 31, 2011 at 12:58 PM, Eric Firing
>>        <ef...@ha... <mailto:ef...@ha...>
>>        <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
>>
>>            On 05/31/2011 05:50 AM, Benjamin Root wrote:
>>         >
>>         >
>>         > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>>         > <ant...@jp...
>>        <mailto:ant...@jp...>
>>        <mailto:ant...@jp...
>>        <mailto:ant...@jp...>>
>>         > <mailto:ant...@jp...
>>        <mailto:ant...@jp...>
>>        <mailto:ant...@jp...
>>        <mailto:ant...@jp...>>>> 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."
>>
>
> 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

On 05/31/2011 08:37 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 1:28 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>
>
>         On Tue, May 31, 2011 at 12:58 PM, Eric Firing
>         <ef...@ha... <mailto:ef...@ha...>
>         <mailto:ef...@ha... <mailto:ef...@ha...>>> wrote:
>
>             On 05/31/2011 05:50 AM, Benjamin Root wrote:
>          >
>          >
>          > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>          > <ant...@jp...
>         <mailto:ant...@jp...>
>         <mailto:ant...@jp...
>         <mailto:ant...@jp...>>
>          > <mailto:ant...@jp...
>         <mailto:ant...@jp...>
>         <mailto:ant...@jp...
>         <mailto:ant...@jp...>>>> 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."

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

Eric

>
> Ben Root
>

On Tue, May 31, 2011 at 1:28 PM, Eric Firing <ef...@ha...> wrote:

> On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>>
>>
>> On Tue, May 31, 2011 at 12:58 PM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>>    On 05/31/2011 05:50 AM, Benjamin Root wrote:
>>     >
>>     >
>>     > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>>     > <ant...@jp...
>>    <mailto:ant...@jp...>
>>     > <mailto:ant...@jp...
>>    <mailto:ant...@jp...>>> 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

On 05/31/2011 08:03 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 12:58 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 05/31/2011 05:50 AM, Benjamin Root wrote:
>      >
>      >
>      > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
>      > <ant...@jp...
>     <mailto:ant...@jp...>
>      > <mailto:ant...@jp...
>     <mailto:ant...@jp...>>> 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
>

On Tue, May 31, 2011 at 12:58 PM, Eric Firing <ef...@ha...> wrote:

> On 05/31/2011 05:50 AM, Benjamin Root wrote:
> >
> >
> > On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
> > <ant...@jp...
> > <mailto:ant...@jp...>> 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

On 05/31/2011 05:50 AM, Benjamin Root wrote:
>
>
> On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G)
> <ant...@jp...
> <mailto:ant...@jp...>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

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

On Tue, May 31, 2011 at 10:34 AM, Mannucci, Anthony J (335G) <
ant...@jp...> 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

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 > Ton...@jp...<mailto:Ton...@jp...>
 4800 Oak Grove Drive,                   http://genesis.jpl.nasa.gov
 Pasadena, CA 91109

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 "<stdin>", line 1, in <module>
>   File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/pylab.py", line 1, in <module>
>     from matplotlib.pylab import *
>   File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/pylab.py", line 216, in <module>
>     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 <module>
>     from matplotlib import axis
>   File "/Library/Frameworks/Python.framework/Versions/7.0/lib/python2.7/site-packages/matplotlib/axis.py", line 10, in <module>
>     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 <module>
>     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

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.

One-line correction to script attached to last post; so use the one 
attached here.

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)<
>> Eri...@no...>  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

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) <
> Eri...@no...> 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.

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<el_...@gm...>   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
> >

On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL) <
Eri...@no...> wrote:

>
>
> efiring wrote:
> >
> > Is it correct that you want interactive mode, except that you want to
> > control when drawing occurs, for purposes of efficiency?
> Thank you for your interest in this question, Eric!
>
> The goal is to indeed control when drawing occurs, but also to not use
> show() (because it cumbersome to have to close umpteen windows so as to
> finish a Matplotlib program that opened lots of figures). (I checked the
> examples that you referred to)
>
> It looks like Matplotlib forces either to use the interactive mode
> (possibly
> inefficient) or to use show() (possibly cumbersome).  I wish that
> Matplotlib
> offers an alternative to this situation, but this looks less and less to be
> the case.  That's something I would like to suggest to the devs.
> :-)
>

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).

Furthermore, I think Eric Firing's point was that mpl is fully capable of
doing what you want.  The automatic draws are only done if the calls come
through pyplot or pylab and if interactive mode is on.  There might be a few
minor exceptions to this rule, but those shouldn't cause significant
overhead.  If you call the drawing commands directly, then a refresh does
not occur until you tell it to with a call to draw().  In pyplot, nearly all
drawing commands have as the final step a call to a function called
"draw_if_interactive()".  This function does exactly what it says.
Therefore, if you want interactive mode, but do not want a refresh after
each pyplot command, then don't use the pyplot commands!  Just use the
objects' drawing commands (which is what pyplot calls).

Also, note that matplotlib is hierarchical.  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.  So, a figure object has (among other things) axes objects
as children.  An axes object has (among other things) various collection
objects from the plotting commands as its children.  Maybe a look at some of
the animation examples might be a good way to illustrate this.  I would
suggest looking at the older animation examples on sourceforge where the
internals are all laid out.

I hope this is helpful,
Ben Root

In the docs for Line2D, it says that the linestyle can be "any drawstyle 
in combination with a linestyle, e.g. 'steps--'."  However, this doesn't 
seem to work in practice.  I believe I have matplotlib 1.0.1 here:

In [2]: from matplotlib import lines

In [3]: line=lines.Line2D([0,1,2],[0,1,4], linestyle='steps--')

In [4]: line.get_drawstyle()
Out[4]: 'default'

In [5]: line.get_linestyle()
Out[5]: '--'


Note that if I specifically set the linestyle using set_linestyle, it 
appears to parse out the drawstyle:

In [11]: line.set_linestyle('steps--')

In [12]: line.get_drawstyle()
Out[12]: 'steps'


However, if I plot the line using the plot() command, the drawstyle is 
correctly set to 'steps'.


In [6]: from matplotlib import pyplot

In [7]: line2=pyplot.plot([0,1,2],[0,1,4], linestyle='steps--')

In [8]: line2
Out[8]: [<matplotlib.lines.Line2D object at 0x114fcb110>]

In [9]: line2[0].get_drawstyle()
Out[9]: 'steps'

In [10]: line2[0].get_linestyle()
Out[10]: '--'

Should Line2D parse out the drawstyle from the linestyle, or are the 
docs wrong about the Line2D linestyle parameters, or am I just 
misunderstanding something here?

Thanks,

Jason

efiring wrote:
> 
> Is it correct that you want interactive mode, except that you want to 
> control when drawing occurs, for purposes of efficiency?
Thank you for your interest in this question, Eric!

The goal is to indeed control when drawing occurs, but also to not use
show() (because it cumbersome to have to close umpteen windows so as to
finish a Matplotlib program that opened lots of figures). (I checked the
examples that you referred to)

It looks like Matplotlib forces either to use the interactive mode (possibly
inefficient) or to use show() (possibly cumbersome).  I wish that Matplotlib
offers an alternative to this situation, but this looks less and less to be
the case.  That's something I would like to suggest to the devs.
:-)
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31735322.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

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.

On Mon, May 30, 2011 at 1:12 PM, Eric Firing <ef...@ha...> wrote:

> On 05/30/2011 05:21 AM, Benjamin Root wrote:
> > On Monday, May 30, 2011, Mondsuechtiger<el_...@gm...>  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
>
>
>
Ah, I see.  I have to turn the clipping attribute off for the object(s)
being plotted, not for the axes object.  I learned something new today...

Ben Root

On 05/30/2011 05:21 AM, Benjamin Root wrote:
> On Monday, May 30, 2011, Mondsuechtiger<el_...@gm...>  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
>

On 05/30/2011 06:42 AM, Eric O LEBIGOT (EOL) wrote:
>
>
> Benjamin Root-2 wrote:
>>
>> On Monday, May 30, 2011, Eric O LEBIGOT (EOL)
>>> I wish that Matplotlib provided a mechanism for bypassing show(), because
>>> show() is actually not my friend. :-)  In fact, with show(), I hate
>>> having
>>> to close one by one each of the 12 figures that my script creates each
>>> time
>>> I run it.
>>>
>>> (…)
>>> stopping a program that was fully or partially in run in non-interactive
>>> mode, without having to use this dreaded show()…
>>> (…)
>>
>> I am not sure exactly what feature you are asking for.  If you are in
>> interactive mode, you could setup a key binding to call a function to
>> close all figures.  Another route to go is to take advantage of
>> subplots and reduce the number of figures you need to have.
>>
> The keybinding idea is interesting, but the goal is to work in
> *non*-interactive mode (for optimization purposes), and the feature I would
> love is simply to be able to display graphs in this mode without using
> show().  Subplots are unfortunately not an option for me, as each of the
> numerous graph must be independent (they are each saved in a specific file).

Is it correct that you want interactive mode, except that you want to 
control when drawing occurs, for purposes of efficiency?  If so, use 
interactive mode, but instead of using the pyplot interface for the 
actual plotting, use the OO interface, and call plt.draw() when you want 
to update a plot.  See
http://matplotlib.sourceforge.net/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related
although this does not give precisely the example to match your case.

Eric

>
>
> Benjamin Root-2 wrote:
>>
>> Also, it bares repeating.  You may be experiencing some bugs with
>> interactive mode in v1.0.0.  Some very important bugfixes were made
>> wrt interactive mode for the v1.0.1 release.  I know the sourceforge
>> page still points to v1.0.0, that is a problem that I hope to have
>> fixed later in the next few days.
>>
> Thanks, I'll definitely check out version 1.0.1.  The feature I wish existed
> is unfortunately relevant to the *non*-interactive mode.
>

I do not know the first thing about Python language.....But things are not
> going well


That's not a "but" but an "of course".  How could they possibly go well
already?
It takes time to learn something.  You will get there, bit by bit.


> and I do not want to use any other
> programs such as GNUplot or other such open source programs which run on
> my linux machine and I am not purchasing any anything developed by
> Micro$oft.
>

I'm curious.  Why not?


> I have come to a road block and need guidance regarding what materials
> (e.g. books) I should purchase to help teach myself python/mathplolib or
> how I should move forward to become proficient use mpl?
>

For Python, there are tons of online tutorials such as Alan Gauld's as well
as any
number of books (Google for recommendations or search the Python Google
Group
for very many iterations of asking for recommendations).

For specific questions, the Python tutor list is great, and now Stack
Overflow is also
very good. For specific Matplotlib questions beyond the tutorial or
examples, either
SO or this list is excellent. There is now a matplotlib book by Sandro Tosi,
too.


> I know little or nothing now so any newbie advice is much appreciated.
>

I recommend that you write down a set of goals for what you want to
accomplish,
and then tackle them one by one.