matplotlib-users Mailing List for matplotlib (Page 10)

On 2012年07月09日 7:33 AM, Brendan Barnwell wrote:
> On 2012年07月09日 06:13, Benjamin Root wrote:
>> On Sun, Jul 8, 2012 at 9:04 PM, Brendan Barnwell<bre...@br...>wrote:
>>> cs = pyplot.contourf(x,y,z,levels=np.arange(50, 220, 20),
>>> cmap=pyplot.cm.jet, extend='both')
>>> cs.cmap.set_under('k')
>>> cs.set_clim(50, 210)
>>> cb = pyplot.colorbar(cs)
>>>
>>> But why do I have to do this? The whole reason I passed in my
>>> specified levels was because I wanted THOSE to be the data limits.
>>> Why is matplotlib expanding the data limits, and thus preventing me
>>> from specifying the "out of range" color using the normal set_under
>>> and set_over methods?
>>>
>>>
>> You are right, that behavior is very inconsistent with the documentation.
>> Looking over the QuadContourSet._process_levels() method, I doubt the
>> problem lies there. While testing, I noticed that whatever color I set for
>> set_under() was always being ignored in the colorbar. I suspect the
>> problem lies there.
>
> 	You mean in the colorbar and/or set_under? I don't think so, because
> the problem occurs whether or not you use a colorbar, and, at least
> for me, set_under works as long as the data limits are set correctly.
> If in my code above, I change set_under("k") to set_under("yellow")
> or whatever else I like, that color is correctly used both in the
> contourf plot and on the colorbar (on the lower arrow). The code that
> I pointed to in _process_levels is setting vmin and vmax. It's
> possible this isn't the root of the problem, but the code certainly
> looks strange and unmotivated, and it is what's causing incorrect clim
> to be set.
>
I assure you it was not unmotivated; but I agree that there is a problem 
here that needs to be solved cleanly. I will look into it.
Eric

On 2012年07月09日 06:13, Benjamin Root wrote:
> On Sun, Jul 8, 2012 at 9:04 PM, Brendan Barnwell<bre...@br...>wrote:
>> cs = pyplot.contourf(x,y,z,levels=np.arange(50, 220, 20),
>> cmap=pyplot.cm.jet, extend='both')
>> cs.cmap.set_under('k')
>> cs.set_clim(50, 210)
>> cb = pyplot.colorbar(cs)
>>
>> But why do I have to do this? The whole reason I passed in my
>> specified levels was because I wanted THOSE to be the data limits.
>> Why is matplotlib expanding the data limits, and thus preventing me
>> from specifying the "out of range" color using the normal set_under
>> and set_over methods?
>>
>>
> You are right, that behavior is very inconsistent with the documentation.
> Looking over the QuadContourSet._process_levels() method, I doubt the
> problem lies there. While testing, I noticed that whatever color I set for
> set_under() was always being ignored in the colorbar. I suspect the
> problem lies there.
	You mean in the colorbar and/or set_under? I don't think so, because 
the problem occurs whether or not you use a colorbar, and, at least 
for me, set_under works as long as the data limits are set correctly. 
 If in my code above, I change set_under("k") to set_under("yellow") 
or whatever else I like, that color is correctly used both in the 
contourf plot and on the colorbar (on the lower arrow). The code that 
I pointed to in _process_levels is setting vmin and vmax. It's 
possible this isn't the root of the problem, but the code certainly 
looks strange and unmotivated, and it is what's causing incorrect clim 
to be set.
-- 
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is 
no path, and leave a trail."
 --author unknown

On Sun, Jul 8, 2012 at 9:04 PM, Brendan Barnwell <bre...@br...>wrote:
> I just spent some time debugging an odd problem. Take this code:
>
> x,y = np.arange(-10,10), np.arange(-10,10)
> x,y = np.meshgrid(x,y)
> z = x**2+y**2
> cs = pyplot.contourf(x,y,z,levels=np.arange(50, 220, 20),
> cmap=pyplot.cm.jet, extend='both')
> cs.cmap.set_under('k')
> cb = pyplot.colorbar(cs)
>
> I was expecting the set_under call to mean that contours outside
> the
> passed level range would be painted in that color. This seems to be
> what the documentation says will happen:
>
> "Unless this [extend argument] is ‘neither’, contour levels are
> automatically added to one or both ends of the range so that all data
> are included. These added ranges are then mapped to the special
> colormap values which default to the ends of the colormap range, but
> can be set via matplotlib.colors.Colormap.set_under() and
> matplotlib.colors.Colormap.set_over() methods."
>
> . . .but it doesn't work. Instead, the levels outside my specified
> range show up colored the same as the lowest selected level (i.e., 50).
>
> I poked around in the code and found that the culprit is this
> section
> in matplotlib.contour.ContourSet._process_levels():
>
> if self.extend in ('both', 'min'):
> self.vmin = 2 * self.levels[0] - self.levels[1]
> if self.extend in ('both', 'max'):
> self.vmax = 2 * self.levels[-1] - self.levels[-2]
>
> Here, if the "extend" argument is given, the code sets the data limits
> to some odd extension of the actual data limits. I can fix it and get
> the correct output by resetting the data limits after plotting my
> contours:
>
> cs = pyplot.contourf(x,y,z,levels=np.arange(50, 220, 20),
> cmap=pyplot.cm.jet, extend='both')
> cs.cmap.set_under('k')
> cs.set_clim(50, 210)
> cb = pyplot.colorbar(cs)
>
> But why do I have to do this? The whole reason I passed in my
> specified levels was because I wanted THOSE to be the data limits.
> Why is matplotlib expanding the data limits, and thus preventing me
> from specifying the "out of range" color using the normal set_under
> and set_over methods?
>
>
You are right, that behavior is very inconsistent with the documentation.
Looking over the QuadContourSet._process_levels() method, I doubt the
problem lies there. While testing, I noticed that whatever color I set for
set_under() was always being ignored in the colorbar. I suspect the
problem lies there.
Ben Root

Hi Eric, Jouni,
Thanks for your replies. I opened an issue here:
https://github.com/matplotlib/matplotlib/issues/992
and wrote an outline of how the PDF backend can be simplified by making use of gc.restore to keep track of the graphics context. In essence the PDF backend would then follow the same logic as the Cairo and Mac OS X backends, so it may be good to compare to these (especially the Cairo backend, since it's written in pure Python and easy to understand).
Best,
-Michiel.
--- On Sun, 7/8/12, Eric Firing <ef...@ha...> wrote:
> From: Eric Firing <ef...@ha...>
> Subject: Re: [Matplotlib-users] Accelerating PDF saved plots
> To: mat...@li...
> Date: Sunday, July 8, 2012, 2:20 AM
> On 2012年07月07日 7:14 PM, Michiel de
> Hoon wrote:
> > Hi,
> >
> > > What kind of outputs can these backends
> create?
> >
> > The Mac OS X backend can create PDFs, but it simply
> uses the pdf backend
> > to do so, so that wouldn't help you.
> > The cairo backend can create PDFs by using cairo, so
> that could be worth
> > trying.
> >
> > > Could make a simple speed comparison between
> these backends
> > > and the original script that uses the PDF
> backend.
> >
> > That would be useful, but keep in mind that there would
> be three options
> > to compare:
> > 1) The current PDF backend;
> > 2) A modified PDF backend;
> > 3) The cairo backend creating PDFs.
> > Since we don't have 2) yet, we cannot do the full
> comparison yet, but
> > still it would be good to know if it is faster to
> create PDFs by using
> > cairo compared to the current PDF backend.
> >
> > > I am assuming the changes you mention
> require quite some work
> > > to make the PDFbackend running faster.
> >
> > I think it is not so bad, since it's mainly a matter of
> removing the
> > stuff from the PDF backend that is no longer needed. Do
> we have a
> > maintainer for the PDF backend? Because I would rather
> rely on him/her
> > to make the changes to this backend. Otherwise, I can
> give it a try, but
> > probably I won't be able to find the time for it within
> this month.
> >
> 
> It would be a good idea to enter a Github ticket for this,
> referring to 
> this email thread.
> 
> Mike D. and Jouni S. have done most of the work on the pdf
> backend.
> 
> Eric
> 
> > Best,
> > -Michiel.
> >
> >
> >
> > --- On *Sat, 7/7/12, Gökhan Sever /<gok...@gm...>/*
> wrote:
> >
> >
> >   From: Gökhan Sever <gok...@gm...>
> >   Subject: Re: [Matplotlib-users]
> Accelerating PDF saved plots
> >   To: "Michiel de Hoon" <mjl...@ya...>
> >   Cc: mat...@li...
> >   Date: Saturday, July 7, 2012,
> 9:05 PM
> >
> >   Hi,
> >
> >   What kind of outputs can these
> backends create? I don't use MAC, so
> >   my question is particularly for
> the Cairo backend. Could make a
> >   simple speed comparison between
> these backends and the original
> >   script that uses the PDF
> backend. I am assuming the changes you
> >   mention require quite some work
> to make the PDFbackend running faster.
> >
> >   Thanks.
> >
> >   On Sat, Jul 7, 2012 at 9:40 AM,
> Michiel de Hoon <mjl...@ya...
> >   </mc/compose?to=mjl...@ya...>>
> wrote:
> >
> >     One reason behind
> the lengthy plot creation times is likely the
> >     PDF backend
> itself.
> >
> >     Whereas the Mac
> OS X and the Cairo backends make use of new_gc
> >     and gc.restore to
> keep track of the graphics context, the PDF
> >     backend uses
> check_gc and an internal stack of graphics
> >     contexts. Since
> nowadays matplotlib has gc.restore
> >     functionality, I
> don't think that that is needed any more.
> >
> >     See this revision
> for when gc.restore was added to matplotlib:
> >
> >     http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=7112
> >
> >     In the same
> revision the Mac OS X and Cairo backends were
> >     modified to make
> use of gc.restore. The PDF backend (and the
> >     postscript
> backend also, btw) can be simplified in the same way
> >     to speed up these
> backends, as well as to reduce the output file
> >     sizes.
> >
> >     Best,
> >     -Michiel.
> >
> >     --- On *Thu,
> 7/5/12, Gökhan Sever /<gok...@gm...
> >   
>  </mc/compose?to=gok...@gm...>>/*
> wrote:
> >
> >
> >     
>  From: Gökhan Sever <gok...@gm...
> >     
>  </mc/compose?to=gok...@gm...>>
> >     
>  Subject: Re: [Matplotlib-users]
> Accelerating PDF saved plots
> >       To:
> "Benjamin Root" <ben...@ou...
> >     
>  </mc/compose?to=ben...@ou...>>
> >       Cc:
> mat...@li...
> >     
>  </mc/compose?to=mat...@li...>
> >     
>  Date: Thursday, July 5, 2012, 2:11 PM
> >
> >
> >
> >       
>  38 * 16 = 608
> >       
>  80 / 608 = 0.1316 seconds per plot
> >
> >       
>  At this point, I doubt you are going to
> get much more
> >       
>  speed-ups. Glad to be of help!
> >
> >       
>  Fabrice -- Good suggestion! I should
> have thought of
> >       
>  that given how much I use that technique
> in doing animation.
> >
> >       
>  Ben Root
> >
> >
> >       I
> am including profiled runs for the records --only first 10
> >     
>  lines to keep e-mail shorter. Total times
> are longer
> >     
>  comparing to the raw run -p executions. I
> believe profiled
> >       run
> has its own call overhead.
> >
> >       I1
> run -p test_speed.py
> >      
>  171889738 function calls (169109959
> primitive calls) in
> >     
>  374.311 seconds
> >
> >       
>  Ordered by: internal time
> >
> >       
>  ncalls tottime percall 
> cumtime percall
> >     
>  filename:lineno(function)
> >        
> 4548012  34.583  
> 0.000  34.583  0.000
> >     
>  {numpy.core.multiarray.array}
> >        
> 1778401  21.012  
> 0.000  46.227  0.000
> >     
>  path.py:86(__init__)
> >       
>  521816  17.844 
>  0.000  17.844  0.000
> >     
>  artist.py:74(__init__)
> >        
> 2947090  15.432  
> 0.000  15.432  0.000
> >     
>  weakref.py:243(__init__)
> >        
> 1778401  9.515  0.000  
> 9.515  0.000 {method 'all'
> >       of
> 'numpy.ndarray' objects}
> >      
>  13691669  8.654  
> 0.000  8.654  0.000 {getattr}
> >        
> 1085280  8.550  
> 0.000  17.629  0.000
> >     
>  core.py:2749(_update_from)
> >        
> 1299904  7.809  
> 0.000  76.060  0.000
> >     
>  markers.py:115(_recache)
> >        
>   38  7.378  
> 0.194  7.378  0.194 {gc.collect}
> >      
>  13564851  6.768  
> 0.000  6.768  0.000 {isinstance}
> >
> >
> >
> >
> >       I1
> run -p test_speed3.py
> >      
>  61658708 function calls (60685172
> primitive calls) in
> >     
>  100.934 seconds
> >
> >       
>  Ordered by: internal time
> >
> >       
>  ncalls tottime percall 
> cumtime percall
> >     
>  filename:lineno(function)
> >       
>  937414  6.638  
> 0.000  6.638  0.000
> >     
>  {numpy.core.multiarray.array}
> >       
>  374227  4.377  
> 0.000  7.500  0.000
> >     
>  path.py:198(iter_segments)
> >        
> 6974613  3.866  0.000  
> 3.866  0.000 {getattr}
> >       
>  542640  3.809  
> 0.000  7.900  0.000
> >     
>  core.py:2749(_update_from)
> >       
>  141361  3.665  
> 0.000  7.136  0.000
> >     
>  transforms.py:99(invalidate)
> >     
>  324688/161136  2.780 
>  0.000  27.747  0.000
> >     
>  transforms.py:1729(transform)
> >        
>  64448  2.753  
> 0.000  64.921  0.001
> >     
>  lines.py:463(draw)
> >       
>  231195  2.748  
> 0.000  7.072  0.000
> >     
>  path.py:86(__init__)
> >     
>  684970/679449  2.679 
>  0.000  3.888  0.000
> >     
>  backend_pdf.py:128(pdfRepr)
> >        
>  67526  2.651  0.000 
>  7.522  0.000
> >     
>  backend_pdf.py:1226(pathOperations)
> >
> >
> >
> >       --
> >     
>  Gökhan
> >
> >     
>  -----Inline Attachment Follows-----
> >
> >
> >     
>  ------------------------------------------------------------------------------
> >     
>  Live Security Virtual Conference
> >     
>  Exclusive live event will cover all the
> ways today's
> >     
>  security and
> >     
>  threat landscape has changed and how IT
> managers can
> >     
>  respond. Discussions
> >     
>  will include endpoint security, mobile
> security and the
> >     
>  latest in malware
> >     
>  threats.
> >       http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >
> >     
>  -----Inline Attachment Follows-----
> >
> >
> >     
>  _______________________________________________
> >     
>  Matplotlib-users mailing list
> >       Mat...@li...
> >     
>  <http://mc/compose?to=Mat...@li...>
> >       https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> >
> >
> >   --
> >   Gökhan
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's
> security and
> > threat landscape has changed and how IT managers can
> respond. Discussions
> > will include endpoint security, mobile security and the
> latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >
> >
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and 
> threat landscape has changed and how IT managers can
> respond. Discussions 
> will include endpoint security, mobile security and the
> latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

Hi Ben !
nope, ESC does not help.
By the way do you have any tip on working with key modifiers?
Thanks a lot,
Best
JF
-
Helmholtz Zentrum Geesthacht
Institut für Werkstoffforschung
Abteilung WPN, Instrument REFSANS
Lichtenbergstr. 1
85747 Garching FRM II
Tel.: +49 (0)89 289 10762
Internet: http://www.frm2.tum.de
---...@gm... schrieb: -----
An: Jea...@hz...
Von: Benjamin Root 
Gesendet von: ben...@gm...
Datum: 07/06/2012 07:32PM
Kopie: mat...@li...
Betreff: Re: [Matplotlib-users] conflicts with navigation bar events
Right, I forgot about that. I am trying to dig through my code to figure out what I did to make this problem go away. In the meantime, does hitting "ESC" at least get you around the problem?
 
Ben Root
----------------------------------------- 
On Wed, Jul 4, 2012 at 3:15 AM, <Jea...@hz...> wrote:
 Hi Ben,
 
 thanks for the tip!
 I nevertheless hit another snag:
 In [12]: [(k,p.rcParams[k]) for k in p.rcParams.keys() if 'keymap' in k]
 Out[12]:
 [('keymap.all_axes', ['a']),
 ('keymap.back', ['left', 'c', 'backspace']),
 ('keymap.forward', ['right', 'v']),
 ('keymap.fullscreen', ['f']),
 ('keymap.grid', ['g']),
 ('keymap.home', ['h', 'r', 'home']),
 ('keymap.pan', ['p']),
 ('keymap.save', ['s']),
 ('keymap.xscale', ['k', 'L']),
 ('keymap.yscale', ['l']),
 ('keymap.zoom', ['o'])]
 
 
 Meaning that up and down ar not in the mapping... Any clue?
 Thanks again
 Cheers
 
JF
 
Helmholtz-Zentrum Geesthacht 
Zentrum für Material- und Küstenforschung GmbH 
Max-Planck-Straße 1 I 21502 Geesthacht I Deutschland/Germany 
Geschäftsführer/Board of Management: Prof. Dr. Wolfgang Kaysser, Dipl.-Ing. Michael Ganß 
Vorsitzender des Aufsichtsrates/Chairman of the Supervisory Board: MinDirig Wilfried Kraus 
Amtsgericht Lübeck HRB 285 GE (Register Court) 
Internet: http://www.hzg.de 

	I just spent some time debugging an odd problem. Take this code:
x,y = np.arange(-10,10), np.arange(-10,10)
x,y = np.meshgrid(x,y)
z = x**2+y**2
cs = pyplot.contourf(x,y,z,levels=np.arange(50, 220, 20), 
cmap=pyplot.cm.jet, extend='both')
cs.cmap.set_under('k')
cb = pyplot.colorbar(cs)
	I was expecting the set_under call to mean that contours outside the 
passed level range would be painted in that color. This seems to be 
what the documentation says will happen:
"Unless this [extend argument] is ‘neither’, contour levels are 
automatically added to one or both ends of the range so that all data 
are included. These added ranges are then mapped to the special 
colormap values which default to the ends of the colormap range, but 
can be set via matplotlib.colors.Colormap.set_under() and 
matplotlib.colors.Colormap.set_over() methods."	
. . .but it doesn't work. Instead, the levels outside my specified 
range show up colored the same as the lowest selected level (i.e., 50).
	I poked around in the code and found that the culprit is this section 
in matplotlib.contour.ContourSet._process_levels():
 if self.extend in ('both', 'min'):
 self.vmin = 2 * self.levels[0] - self.levels[1]
 if self.extend in ('both', 'max'):
 self.vmax = 2 * self.levels[-1] - self.levels[-2]
Here, if the "extend" argument is given, the code sets the data limits 
to some odd extension of the actual data limits. I can fix it and get 
the correct output by resetting the data limits after plotting my 
contours:
cs = pyplot.contourf(x,y,z,levels=np.arange(50, 220, 20), 
cmap=pyplot.cm.jet, extend='both')
cs.cmap.set_under('k')
cs.set_clim(50, 210)
cb = pyplot.colorbar(cs)
	But why do I have to do this? The whole reason I passed in my 
specified levels was because I wanted THOSE to be the data limits. 
Why is matplotlib expanding the data limits, and thus preventing me 
from specifying the "out of range" color using the normal set_under 
and set_over methods?
-- 
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is 
no path, and leave a trail."
 --author unknown

http://kamiasek.kx.cz/daqowrtau/669669.html

On 2012年07月07日 7:14 PM, Michiel de Hoon wrote:
> Hi,
>
> > What kind of outputs can these backends create?
>
> The Mac OS X backend can create PDFs, but it simply uses the pdf backend
> to do so, so that wouldn't help you.
> The cairo backend can create PDFs by using cairo, so that could be worth
> trying.
>
> > Could make a simple speed comparison between these backends
> > and the original script that uses the PDF backend.
>
> That would be useful, but keep in mind that there would be three options
> to compare:
> 1) The current PDF backend;
> 2) A modified PDF backend;
> 3) The cairo backend creating PDFs.
> Since we don't have 2) yet, we cannot do the full comparison yet, but
> still it would be good to know if it is faster to create PDFs by using
> cairo compared to the current PDF backend.
>
> > I am assuming the changes you mention require quite some work
> > to make the PDFbackend running faster.
>
> I think it is not so bad, since it's mainly a matter of removing the
> stuff from the PDF backend that is no longer needed. Do we have a
> maintainer for the PDF backend? Because I would rather rely on him/her
> to make the changes to this backend. Otherwise, I can give it a try, but
> probably I won't be able to find the time for it within this month.
>
It would be a good idea to enter a Github ticket for this, referring to 
this email thread.
Mike D. and Jouni S. have done most of the work on the pdf backend.
Eric
> Best,
> -Michiel.
>
>
>
> --- On *Sat, 7/7/12, Gökhan Sever /<gok...@gm...>/* wrote:
>
>
> From: Gökhan Sever <gok...@gm...>
> Subject: Re: [Matplotlib-users] Accelerating PDF saved plots
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li...
> Date: Saturday, July 7, 2012, 9:05 PM
>
> Hi,
>
> What kind of outputs can these backends create? I don't use MAC, so
> my question is particularly for the Cairo backend. Could make a
> simple speed comparison between these backends and the original
> script that uses the PDF backend. I am assuming the changes you
> mention require quite some work to make the PDFbackend running faster.
>
> Thanks.
>
> On Sat, Jul 7, 2012 at 9:40 AM, Michiel de Hoon <mjl...@ya...
> </mc/compose?to=mjl...@ya...>> wrote:
>
> One reason behind the lengthy plot creation times is likely the
> PDF backend itself.
>
> Whereas the Mac OS X and the Cairo backends make use of new_gc
> and gc.restore to keep track of the graphics context, the PDF
> backend uses check_gc and an internal stack of graphics
> contexts. Since nowadays matplotlib has gc.restore
> functionality, I don't think that that is needed any more.
>
> See this revision for when gc.restore was added to matplotlib:
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=7112
>
> In the same revision the Mac OS X and Cairo backends were
> modified to make use of gc.restore. The PDF backend (and the
> postscript backend also, btw) can be simplified in the same way
> to speed up these backends, as well as to reduce the output file
> sizes.
>
> Best,
> -Michiel.
>
> --- On *Thu, 7/5/12, Gökhan Sever /<gok...@gm...
> </mc/compose?to=gok...@gm...>>/* wrote:
>
>
> From: Gökhan Sever <gok...@gm...
> </mc/compose?to=gok...@gm...>>
> Subject: Re: [Matplotlib-users] Accelerating PDF saved plots
> To: "Benjamin Root" <ben...@ou...
> </mc/compose?to=ben...@ou...>>
> Cc: mat...@li...
> </mc/compose?to=mat...@li...>
> Date: Thursday, July 5, 2012, 2:11 PM
>
>
>
> 38 * 16 = 608
> 80 / 608 = 0.1316 seconds per plot
>
> At this point, I doubt you are going to get much more
> speed-ups. Glad to be of help!
>
> Fabrice -- Good suggestion! I should have thought of
> that given how much I use that technique in doing animation.
>
> Ben Root
>
>
> I am including profiled runs for the records --only first 10
> lines to keep e-mail shorter. Total times are longer
> comparing to the raw run -p executions. I believe profiled
> run has its own call overhead.
>
> I1 run -p test_speed.py
> 171889738 function calls (169109959 primitive calls) in
> 374.311 seconds
>
> Ordered by: internal time
>
> ncalls tottime percall cumtime percall
> filename:lineno(function)
> 4548012 34.583 0.000 34.583 0.000
> {numpy.core.multiarray.array}
> 1778401 21.012 0.000 46.227 0.000
> path.py:86(__init__)
> 521816 17.844 0.000 17.844 0.000
> artist.py:74(__init__)
> 2947090 15.432 0.000 15.432 0.000
> weakref.py:243(__init__)
> 1778401 9.515 0.000 9.515 0.000 {method 'all'
> of 'numpy.ndarray' objects}
> 13691669 8.654 0.000 8.654 0.000 {getattr}
> 1085280 8.550 0.000 17.629 0.000
> core.py:2749(_update_from)
> 1299904 7.809 0.000 76.060 0.000
> markers.py:115(_recache)
> 38 7.378 0.194 7.378 0.194 {gc.collect}
> 13564851 6.768 0.000 6.768 0.000 {isinstance}
>
>
>
>
> I1 run -p test_speed3.py
> 61658708 function calls (60685172 primitive calls) in
> 100.934 seconds
>
> Ordered by: internal time
>
> ncalls tottime percall cumtime percall
> filename:lineno(function)
> 937414 6.638 0.000 6.638 0.000
> {numpy.core.multiarray.array}
> 374227 4.377 0.000 7.500 0.000
> path.py:198(iter_segments)
> 6974613 3.866 0.000 3.866 0.000 {getattr}
> 542640 3.809 0.000 7.900 0.000
> core.py:2749(_update_from)
> 141361 3.665 0.000 7.136 0.000
> transforms.py:99(invalidate)
> 324688/161136 2.780 0.000 27.747 0.000
> transforms.py:1729(transform)
> 64448 2.753 0.000 64.921 0.001
> lines.py:463(draw)
> 231195 2.748 0.000 7.072 0.000
> path.py:86(__init__)
> 684970/679449 2.679 0.000 3.888 0.000
> backend_pdf.py:128(pdfRepr)
> 67526 2.651 0.000 7.522 0.000
> backend_pdf.py:1226(pathOperations)
>
>
>
> --
> Gökhan
>
> -----Inline Attachment Follows-----
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's
> security and
> threat landscape has changed and how IT managers can
> respond. Discussions
> will include endpoint security, mobile security and the
> latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> -----Inline Attachment Follows-----
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <http://mc/compose?to=Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> --
> Gökhan
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Michiel de Hoon <mjl...@ya...> writes:
> I think it is not so bad, since it's mainly a matter of removing the
> stuff from the PDF backend that is no longer needed. Do we have a
> maintainer for the PDF backend? Because I would rather rely on him/her
> to make the changes to this backend. 
That would be me. Can you outline what parts you think can be removed?
I'm currently travelling and don't always have an Internet connection,
or much time available, so turnaround can be slow.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi,
> What kind of outputs can these backends create?
The Mac OS X backend can create PDFs, but it simply uses the pdf backend to do so, so that wouldn't help you.
The cairo backend can create PDFs by using cairo, so that could be worth trying.
> Could make a simple 
speed comparison between these backends
> and the original script that 
uses the PDF backend.
That would be useful, but keep in mind that there would be three options to compare:
1) The current PDF backend;
2) A modified PDF backend;
3) The cairo backend creating PDFs.
Since we don't have 2) yet, we cannot do the full comparison yet, but still it would be good to know if it is faster to create PDFs by using cairo compared to the current PDF backend.
> I am assuming the changes you mention require 
quite some work
> to make the PDFbackend running faster.
I think it is not so bad, since it's mainly a matter of removing the stuff from the PDF backend that is no longer needed. Do we have a maintainer for the PDF backend? Because I would rather rely on him/her to make the changes to this backend. Otherwise, I can give it a try, but probably I won't be able to find the time for it within this month.
Best,
-Michiel.
--- On Sat, 7/7/12, Gökhan Sever <gok...@gm...> wrote:
From: Gökhan Sever <gok...@gm...>
Subject: Re: [Matplotlib-users] Accelerating PDF saved plots
To: "Michiel de Hoon" <mjl...@ya...>
Cc: mat...@li...
Date: Saturday, July 7, 2012, 9:05 PM
Hi,
What kind of outputs can these backends create? I don't use MAC, so my question is particularly for the Cairo backend. Could make a simple speed comparison between these backends and the original script that uses the PDF backend. I am assuming the changes you mention require quite some work to make the PDFbackend running faster.
Thanks.
On Sat, Jul 7, 2012 at 9:40 AM, Michiel de Hoon <mjl...@ya...> wrote:
One reason behind the lengthy plot creation times is likely the PDF backend itself. 
Whereas the Mac OS X and the Cairo backends make use of new_gc and gc.restore to keep track of the graphics context, the PDF backend uses check_gc and an internal stack of graphics contexts. Since nowadays matplotlib has gc.restore functionality, I don't think that that is needed any more.
See this revision for when gc.restore was added to matplotlib:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=7112
In the same revision the Mac OS X and Cairo backends were modified to make use of gc.restore. The PDF backend (and the postscript backend also, btw) can be simplified in the same way to speed up these backends, as well as to reduce the output file sizes.
Best,
-Michiel.
--- On Thu, 7/5/12, Gökhan
 Sever <gok...@gm...> wrote:
From: Gökhan Sever <gok...@gm...>
Subject: Re: [Matplotlib-users] Accelerating PDF saved plots
To: "Benjamin Root" <ben...@ou...>
Cc: mat...@li...
Date: Thursday, July 5, 2012, 2:11 PM
38 * 16 = 608
80 / 608 = 0.1316 seconds per plot
At this point, I doubt you are going to get much more speed-ups. Glad to be of help!
Fabrice -- Good suggestion! I should have thought of that given how much I use that technique in doing animation.
Ben Root
I am including profiled runs for the records --only first 10 lines to keep e-mail shorter. Total times are longer comparing to the raw run -p executions. I believe profiled run has its own call overhead.
I1 run -p test_speed.py
 171889738 function calls (169109959 primitive calls) in 374.311 seconds
  Ordered by: internal time
  ncalls tottime percall cumtime percall filename:lineno(function)
 4548012  34.583  0.000  34.583  0.000 {numpy.core.multiarray.array} 1778401  21.012  0.000  46.227  0.000 path.py:86(__init__)  521816  17.844  0.000  17.844  0.000 artist.py:74(__init__)
 2947090  15.432  0.000  15.432  0.000 weakref.py:243(__init__) 1778401  9.515  0.000  9.515  0.000 {method 'all' of 'numpy.ndarray' objects} 13691669  8.654  0.000  8.654  0.000 {getattr}
 1085280  8.550  0.000  17.629  0.000 core.py:2749(_update_from) 1299904  7.809  0.000  76.060  0.000 markers.py:115(_recache)    38  7.378  0.194  7.378  0.194 {gc.collect}
 13564851  6.768  0.000  6.768  0.000 {isinstance}
I1 run -p test_speed3.py 61658708 function calls (60685172 primitive calls) in 100.934 seconds
  Ordered by: internal time
  ncalls tottime percall cumtime percall filename:lineno(function)  937414  6.638  0.000  6.638  0.000 {numpy.core.multiarray.array}
  374227  4.377  0.000  7.500  0.000 path.py:198(iter_segments) 6974613  3.866  0.000  3.866  0.000 {getattr}  542640  3.809  0.000  7.900  0.000 core.py:2749(_update_from)
  141361  3.665  0.000  7.136  0.000 transforms.py:99(invalidate)324688/161136  2.780  0.000  27.747  0.000 transforms.py:1729(transform)  64448  2.753  0.000  64.921  0.001 lines.py:463(draw)
  231195  2.748  0.000  7.072  0.000 path.py:86(__init__)684970/679449  2.679  0.000  3.888  0.000 backend_pdf.py:128(pdfRepr)  67526  2.651  0.000  7.522  0.000 backend_pdf.py:1226(pathOperations)
-- 
Gökhan
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
-----Inline Attachment Follows-----
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Gökhan

Hi,
What kind of outputs can these backends create? I don't use MAC, so my
question is particularly for the Cairo backend. Could make a simple speed
comparison between these backends and the original script that uses the PDF
backend. I am assuming the changes you mention require quite some work to
make the PDFbackend running faster.
Thanks.
On Sat, Jul 7, 2012 at 9:40 AM, Michiel de Hoon <mjl...@ya...> wrote:
> One reason behind the lengthy plot creation times is likely the PDF
> backend itself.
>
> Whereas the Mac OS X and the Cairo backends make use of new_gc and
> gc.restore to keep track of the graphics context, the PDF backend uses
> check_gc and an internal stack of graphics contexts. Since nowadays
> matplotlib has gc.restore functionality, I don't think that that is needed
> any more.
>
> See this revision for when gc.restore was added to matplotlib:
>
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=7112
>
> In the same revision the Mac OS X and Cairo backends were modified to make
> use of gc.restore. The PDF backend (and the postscript backend also, btw)
> can be simplified in the same way to speed up these backends, as well as to
> reduce the output file sizes.
>
> Best,
> -Michiel.
>
> --- On *Thu, 7/5/12, Gökhan Sever <gok...@gm...>* wrote:
>
>
> From: Gökhan Sever <gok...@gm...>
> Subject: Re: [Matplotlib-users] Accelerating PDF saved plots
> To: "Benjamin Root" <ben...@ou...>
> Cc: mat...@li...
> Date: Thursday, July 5, 2012, 2:11 PM
>
>
>
> 38 * 16 = 608
> 80 / 608 = 0.1316 seconds per plot
>
> At this point, I doubt you are going to get much more speed-ups. Glad to
> be of help!
>
> Fabrice -- Good suggestion! I should have thought of that given how much
> I use that technique in doing animation.
>
> Ben Root
>
>
> I am including profiled runs for the records --only first 10 lines to keep
> e-mail shorter. Total times are longer comparing to the raw run -p
> executions. I believe profiled run has its own call overhead.
>
> I1 run -p test_speed.py
> 171889738 function calls (169109959 primitive calls) in 374.311 seconds
>
> Ordered by: internal time
>
> ncalls tottime percall cumtime percall filename:lineno(function)
> 4548012 34.583 0.000 34.583 0.000 {numpy.core.multiarray.array}
> 1778401 21.012 0.000 46.227 0.000 path.py:86(__init__)
> 521816 17.844 0.000 17.844 0.000 artist.py:74(__init__)
> 2947090 15.432 0.000 15.432 0.000 weakref.py:243(__init__)
> 1778401 9.515 0.000 9.515 0.000 {method 'all' of
> 'numpy.ndarray' objects}
> 13691669 8.654 0.000 8.654 0.000 {getattr}
> 1085280 8.550 0.000 17.629 0.000 core.py:2749(_update_from)
> 1299904 7.809 0.000 76.060 0.000 markers.py:115(_recache)
> 38 7.378 0.194 7.378 0.194 {gc.collect}
> 13564851 6.768 0.000 6.768 0.000 {isinstance}
>
>
>
>
> I1 run -p test_speed3.py
> 61658708 function calls (60685172 primitive calls) in 100.934 seconds
>
> Ordered by: internal time
>
> ncalls tottime percall cumtime percall filename:lineno(function)
> 937414 6.638 0.000 6.638 0.000 {numpy.core.multiarray.array}
> 374227 4.377 0.000 7.500 0.000 path.py:198(iter_segments)
> 6974613 3.866 0.000 3.866 0.000 {getattr}
> 542640 3.809 0.000 7.900 0.000 core.py:2749(_update_from)
> 141361 3.665 0.000 7.136 0.000 transforms.py:99(invalidate)
> 324688/161136 2.780 0.000 27.747 0.000
> transforms.py:1729(transform)
> 64448 2.753 0.000 64.921 0.001 lines.py:463(draw)
> 231195 2.748 0.000 7.072 0.000 path.py:86(__init__)
> 684970/679449 2.679 0.000 3.888 0.000
> backend_pdf.py:128(pdfRepr)
> 67526 2.651 0.000 7.522 0.000
> backend_pdf.py:1226(pathOperations)
>
>
>
> --
> Gökhan
>
> -----Inline Attachment Follows-----
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
> -----Inline Attachment Follows-----
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...<http://mc/compose?to=Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
-- 
Gökhan

On Fri, Jul 6, 2012 at 5:39 PM, Chao YUE <cha...@gm...> wrote:
> dear all,
>
> I want to build a 5X3 subplots matrix that I want the xaxis is shared only
> on the same column and yaxis shared only on the same row.
> While using plt.subplots(5,3,sharex=True, sharey=True) will put all
> subplots as both shared xaxis and yaxis.
>
> The other option is to do like this to create 2X2 subplots with desired
> feature, Yet I guess doing the same for 5X3 subplots could be tedious?
> Does anyone has some idea?
> fig=figure()
> ax1=fig.add_subplot(221)
> ax2=fig.add_subplot(222,sharey=ax1)
> ax3=fig.add_subplot(223,sharex=ax1)
> ax4=fig.add_subplot(224,sharex=ax2,sharey=ax3)
>
> Thanks a lot et cheers,
>
> Chao
>
>
Chao,
Such a feature is not in any of the current releases, (although it can be
done manually, but it is tedious). However, in the development branch, the
subplots() function now accepts strings of "row", "col", "all", or "none"
for both the sharex and sharey kwargs. So, for you, you can call
subplots() with sharex="col" and sharey="row" to get what you want. This
will also have a side-effect of having the y-tick labels show up only on
the first column and the x-tick labels show up only on the last row. This
is a new feature, so bug reports would be welcomed!
Cheers!
Ben Root

One reason behind the lengthy plot creation times is likely the PDF backend itself. 
Whereas the Mac OS X and the Cairo backends make use of new_gc and gc.restore to keep track of the graphics context, the PDF backend uses check_gc and an internal stack of graphics contexts. Since nowadays matplotlib has gc.restore functionality, I don't think that that is needed any more.
See this revision for when gc.restore was added to matplotlib:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib?view=revision&revision=7112
In the same revision the Mac OS X and Cairo backends were modified to make use of gc.restore. The PDF backend (and the postscript backend also, btw) can be simplified in the same way to speed up these backends, as well as to reduce the output file sizes.
Best,
-Michiel.
--- On Thu, 7/5/12, Gökhan Sever <gok...@gm...> wrote:
From: Gökhan Sever <gok...@gm...>
Subject: Re: [Matplotlib-users] Accelerating PDF saved plots
To: "Benjamin Root" <ben...@ou...>
Cc: mat...@li...
Date: Thursday, July 5, 2012, 2:11 PM
38 * 16 = 608
80 / 608 = 0.1316 seconds per plot
At this point, I doubt you are going to get much more speed-ups. Glad to be of help!
Fabrice -- Good suggestion! I should have thought of that given how much I use that technique in doing animation.
Ben Root
I am including profiled runs for the records --only first 10 lines to keep e-mail shorter. Total times are longer comparing to the raw run -p executions. I believe profiled run has its own call overhead.
I1 run -p test_speed.py
 171889738 function calls (169109959 primitive calls) in 374.311 seconds
  Ordered by: internal time
  ncalls tottime percall cumtime percall filename:lineno(function)
 4548012  34.583  0.000  34.583  0.000 {numpy.core.multiarray.array} 1778401  21.012  0.000  46.227  0.000 path.py:86(__init__)  521816  17.844  0.000  17.844  0.000 artist.py:74(__init__)
 2947090  15.432  0.000  15.432  0.000 weakref.py:243(__init__) 1778401  9.515  0.000  9.515  0.000 {method 'all' of 'numpy.ndarray' objects} 13691669  8.654  0.000  8.654  0.000 {getattr}
 1085280  8.550  0.000  17.629  0.000 core.py:2749(_update_from) 1299904  7.809  0.000  76.060  0.000 markers.py:115(_recache)    38  7.378  0.194  7.378  0.194 {gc.collect}
 13564851  6.768  0.000  6.768  0.000 {isinstance}
I1 run -p test_speed3.py 61658708 function calls (60685172 primitive calls) in 100.934 seconds
  Ordered by: internal time
  ncalls tottime percall cumtime percall filename:lineno(function)  937414  6.638  0.000  6.638  0.000 {numpy.core.multiarray.array}
  374227  4.377  0.000  7.500  0.000 path.py:198(iter_segments) 6974613  3.866  0.000  3.866  0.000 {getattr}  542640  3.809  0.000  7.900  0.000 core.py:2749(_update_from)
  141361  3.665  0.000  7.136  0.000 transforms.py:99(invalidate)324688/161136  2.780  0.000  27.747  0.000 transforms.py:1729(transform)  64448  2.753  0.000  64.921  0.001 lines.py:463(draw)
  231195  2.748  0.000  7.072  0.000 path.py:86(__init__)684970/679449  2.679  0.000  3.888  0.000 backend_pdf.py:128(pdfRepr)  67526  2.651  0.000  7.522  0.000 backend_pdf.py:1226(pathOperations)
-- 
Gökhan
-----Inline Attachment Follows-----
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
-----Inline Attachment Follows-----
_______________________________________________
Matplotlib-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 2012年07月05日 11:33 PM, TP wrote:
> Hi everybody,
>
> The following is a small test yielding a segmentation fault with PySide, but
> not with PyQt4.
>
> To test with PyQt4, use:
> $ python example.py
>
> To test with PySide:
> $ python example.py pyside
>
> With PySide, a segmentation fault appears as soon as the mouse cursor is
> hovering the plot area. Without the NavigationToolbar (try to comment the
> corresponding lines), the problem does not appear. It may be related to the
> display of mouse coordinates in the NavigationToolbar, because when the mouse
> is hovering the NavigationToolbar, no segfault appears.
>
> These are the versions of Qt, PySide, and Matplotlib on my machine:
>>>> from PySide import QtCore
>>>> QtCore.qVersion()
> '4.8.1'
>>>> from PySide import __version__
>>>> __version__
> '1.1.0'
>>>> import matplotlib
>>>> matplotlib.__version__
> '1.1.1rc'
>
> Is this a bug? If yes, does any workaround exist?
Yes, it's a bug, but most likely in PySide. Mpl does not use any 
extension code specific to Qt.
Eric
>
> Thanks in advance,
>
> TP
>
> ########### example.py ############
> #!/usr/bin/env python
>
> import sys
>
> if len(sys.argv) >= 2 and sys.argv[1] == "pyside":
> from os import environ
> environ['QT_API'] = 'pyside'
>
> from PySide.QtCore import *
> from PySide.QtGui import *
> else:
> from PyQt4.QtCore import *
> from PyQt4.QtGui import *
>
>
> from matplotlib.figure import Figure
> from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as
> FigureCanvas
> from matplotlib.backends.backend_qt4agg import NavigationToolbar2QTAgg
>
> class MplCanvasXY( FigureCanvas ):
>
> def __init__( self, title = None, xlabel = None, ylabel = None,
> parent=None ):
>
> self.fig = Figure()
> self.axes = self.fig.add_subplot(111)
> self.axes.grid(True)
>
> FigureCanvas.__init__( self, self.fig )
> self.setParent( parent )
>
>
> app = QApplication( sys.argv )
> d = QDialog()
>
> vb = QVBoxLayout()
> canvas = MplCanvasXY()
>
> vb.addWidget( canvas )
> navigationToolbar = NavigationToolbar2QTAgg(
> parent = canvas
> , canvas = canvas )
> vb.addWidget( navigationToolbar )
> d.setLayout( vb )
>
> d.show()
> sys.exit( app.exec_() )
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

dear all,
I want to build a 5X3 subplots matrix that I want the xaxis is shared only
on the same column and yaxis shared only on the same row.
While using plt.subplots(5,3,sharex=True, sharey=True) will put all
subplots as both shared xaxis and yaxis.
The other option is to do like this to create 2X2 subplots with desired
feature, Yet I guess doing the same for 5X3 subplots could be tedious?
Does anyone has some idea?
 fig=figure()
ax1=fig.add_subplot(221)
ax2=fig.add_subplot(222,sharey=ax1)
ax3=fig.add_subplot(223,sharex=ax1)
ax4=fig.add_subplot(224,sharex=ax2,sharey=ax3)
Thanks a lot et cheers,
Chao
-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

On Fri, Jul 6, 2012 at 2:36 PM, Saurav Pathak <sa...@sa...> wrote:
> Hi,
>
> I would often save figures after show() from the savefig button on the
> navigation toolbar. I would like to trim white spaces using something
> akin to bbox_inches='tight', but haven't been able to figure out how. I
> tried adding the following to matplotlibrc, but to no avail:
>
> savefig.bbox_inches : tight
>
> The error message is that savefig.bbox_inches is a bad key
>
> Could someone let me know how to do this, if it can be done? I am using
> Matplotlib 1.1.0
>
> Thanks,
> Saurav
>
>
Saurav,
Currently, there is no way to do what you want in v1.1.x. However, I do
think it is a reasonable feature request and you should file an issue
ticket on the github website.
Cheers!
Ben Root

Saurav Pathak:
> I would often save figures after show() from the savefig button on the
> navigation toolbar. I would like to trim white spaces using something
> akin to bbox_inches='tight', but haven't been able to figure out how. I
> tried adding the following to matplotlibrc, but to no avail.
Adjust the position of your 'axes' rectangle, e. g.
from pylab import *
x=linspace(0,4*pi,500); y=sin(x)
*axes([0.05,0.05,0.93,0.92])*
plot(x,y); show()
the details will depend on the size of your labels.
==
Jerzy Karczmarczuk

Hi,
I would often save figures after show() from the savefig button on the 
navigation toolbar. I would like to trim white spaces using something 
akin to bbox_inches='tight', but haven't been able to figure out how. I 
tried adding the following to matplotlibrc, but to no avail:
savefig.bbox_inches : tight
The error message is that savefig.bbox_inches is a bad key
Could someone let me know how to do this, if it can be done? I am using 
Matplotlib 1.1.0
Thanks,
Saurav

On Wed, Jul 4, 2012 at 3:15 AM, <Jea...@hz...> wrote:
> Hi Ben,
>
> thanks for the tip!
> I nevertheless hit another snag:
> In [12]: [(k,p.rcParams[k]) for k in p.rcParams.keys() if 'keymap' in k]
> Out[12]:
> [('keymap.all_axes', ['a']),
> ('keymap.back', ['left', 'c', 'backspace']),
> ('keymap.forward', ['right', 'v']),
> ('keymap.fullscreen', ['f']),
> ('keymap.grid', ['g']),
> ('keymap.home', ['h', 'r', 'home']),
> ('keymap.pan', ['p']),
> ('keymap.save', ['s']),
> ('keymap.xscale', ['k', 'L']),
> ('keymap.yscale', ['l']),
> ('keymap.zoom', ['o'])]
>
>
> Meaning that up and down ar not in the mapping... Any clue?
> Thanks again
> Cheers
> JF
>
>
Right, I forgot about that. I am trying to dig through my code to figure
out what I did to make this problem go away. In the meantime, does hitting
"ESC" at least get you around the problem?
Ben Root

Hi all,
I am currently trying to use matplotlib with wxPython and all is going well except for one annoying issue that I can't figure out. 
I initialize a wxcanvas object with a figure and then throughout the life of the program I want the canvas' figure to change and display the corresponding plot. I can get the change of figure, but when the program goes to plot, the figure isn't the right size. It changes to the right size only when I manually resize the figure (see attached images). Is there some command that I am missing? This is the update sequence I am using:
self.figure = figure
 
 self.canvas.figure.clear()
 self.canvas.figure = self.figure
 self.canvas.draw()
 self.color_background()
 
 #self.GetParent().Layout()
 #self.SetSizer(self.main_sizer)
 #self.Fit()
 self.SendSizeEvent()
As you can tell from the comments (there are more in my code), I have tried a variety of ways to update the figure off the bat.
Thanks!
Josh

Hi everybody,
The following is a small test yielding a segmentation fault with PySide, but 
not with PyQt4.
To test with PyQt4, use:
$ python example.py
To test with PySide:
$ python example.py pyside
With PySide, a segmentation fault appears as soon as the mouse cursor is 
hovering the plot area. Without the NavigationToolbar (try to comment the 
corresponding lines), the problem does not appear. It may be related to the 
display of mouse coordinates in the NavigationToolbar, because when the mouse 
is hovering the NavigationToolbar, no segfault appears.
These are the versions of Qt, PySide, and Matplotlib on my machine:
>>> from PySide import QtCore
>>> QtCore.qVersion()
'4.8.1'
>>> from PySide import __version__
>>> __version__
'1.1.0'
>>> import matplotlib
>>> matplotlib.__version__
'1.1.1rc'
Is this a bug? If yes, does any workaround exist?
Thanks in advance,
TP
########### example.py ############
#!/usr/bin/env python
import sys
if len(sys.argv) >= 2 and sys.argv[1] == "pyside":
 from os import environ
 environ['QT_API'] = 'pyside'
 from PySide.QtCore import *
 from PySide.QtGui import *
else:
 from PyQt4.QtCore import *
 from PyQt4.QtGui import *
from matplotlib.figure import Figure
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as 
FigureCanvas
from matplotlib.backends.backend_qt4agg import NavigationToolbar2QTAgg
class MplCanvasXY( FigureCanvas ):
 def __init__( self, title = None, xlabel = None, ylabel = None, 
parent=None ):
 self.fig = Figure()
 self.axes = self.fig.add_subplot(111)
 self.axes.grid(True)
 FigureCanvas.__init__( self, self.fig )
 self.setParent( parent )
app = QApplication( sys.argv )
d = QDialog()
vb = QVBoxLayout()
canvas = MplCanvasXY()
vb.addWidget( canvas )
navigationToolbar = NavigationToolbar2QTAgg(
 parent = canvas
 , canvas = canvas )
vb.addWidget( navigationToolbar )
d.setLayout( vb )
d.show()
sys.exit( app.exec_() )

On Thu, Jul 5, 2012 at 12:17 PM, Benjamin Root <ben...@ou...> wrote:
>
> Actually, looking at Fabrice's code, you might be able to get it to be
> slightly faster. Lines 39-41 should be protected by a "if i == 0"
> statement because it only needs to be done once. Furthermore, you might
> get some more improvements if you allow the subplots to share_all, in which
> case, you only need to set the limits and maybe the scale and the locator
> once.
>
> Cheers!
> Ben Root
>
>
Good catch. Bringing lines 39-41 in the if i==0 block makes the label texts
appear jagged. See my output for this case at ->
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed3_jaggedlabels.pdf
Putting these lines right below main fig and grid object creations make
them look normal, and this case saves me 3-5 more seconds.
Setting share_all option to 1 makes x-ticks unreasonably placed on the
axes. As if the share_all option is applied only to the first plot call.
See the example output at ->
http://atmos.uwyo.edu/~gsever/data/matplotlib/test_speed3_badxaxes.pdf
I actually started with share_all=1 from this example ->
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/examples/demo_axes_grid.py
Particularly the construction given in def demo_grid_with_single_cbar(fig).
However I noticed, this behavior earlier and explicit grid calls solved
this issue.

On Thu, Jul 5, 2012 at 1:55 PM, Gökhan Sever <gok...@gm...> wrote:
> And you might get back more memory if you didn't have to have all the data
>> in memory at once, but that may or may not help you. The only other
>> suggestion I can make is to attempt to eliminate the overhead in the inner
>> loop. Essentially, I would try making a single figure and a single
>> AxesGrid object (before the outer loop). Then go over each subplot in the
>> AxesGrid object and set the limits, the log scale, the ticks and the tick
>> locater (I wouldn't be surprised if that is eating up cpu cycles). All of
>> this would be done once before the loop you have right now. Then create
>> the PdfPages object, and loop over all of the plots you have, essentially
>> recycling the figure and AxesGrid object.
>>
>> At end of the outer loop, instead of closing the figure, you should call
>> "remove()" for each plot element you made. Essentially, as you loop over
>> the inner loop, save the output of the plot() call to a list, and then when
>> done with those plots, pop each element of that list and call "remove()" to
>> take it out of the subplot. This will let the subplot axes retain the
>> properties you set earlier.
>>
>> I hope that made sense.
>> Ben Root
>>
>>
> Hi Ben,
>
> I should have data the available at once, as I directly read that array
> from a netcdf file. The memory requirement for my data is small comparing
> to overhead added once plot creation is started. Fabrice's reply includes
> most of what you describe except the remove call part. These changes made
> big impact to lower my execution times. Thank you again for your
> explanation.
>
>
> --
> Gökhan
>
Actually, looking at Fabrice's code, you might be able to get it to be
slightly faster. Lines 39-41 should be protected by a "if i == 0"
statement because it only needs to be done once. Furthermore, you might
get some more improvements if you allow the subplots to share_all, in which
case, you only need to set the limits and maybe the scale and the locator
once.
Cheers!
Ben Root

>
>
>> 38 * 16 = 608
> 80 / 608 = 0.1316 seconds per plot
>
> At this point, I doubt you are going to get much more speed-ups. Glad to
> be of help!
>
> Fabrice -- Good suggestion! I should have thought of that given how much
> I use that technique in doing animation.
>
> Ben Root
>
>
I am including profiled runs for the records --only first 10 lines to keep
e-mail shorter. Total times are longer comparing to the raw run -p
executions. I believe profiled run has its own call overhead.
I1 run -p test_speed.py
 171889738 function calls (169109959 primitive calls) in 374.311 seconds
 Ordered by: internal time
 ncalls tottime percall cumtime percall filename:lineno(function)
 4548012 34.583 0.000 34.583 0.000 {numpy.core.multiarray.array}
 1778401 21.012 0.000 46.227 0.000 path.py:86(__init__)
 521816 17.844 0.000 17.844 0.000 artist.py:74(__init__)
 2947090 15.432 0.000 15.432 0.000 weakref.py:243(__init__)
 1778401 9.515 0.000 9.515 0.000 {method 'all' of
'numpy.ndarray' objects}
 13691669 8.654 0.000 8.654 0.000 {getattr}
 1085280 8.550 0.000 17.629 0.000 core.py:2749(_update_from)
 1299904 7.809 0.000 76.060 0.000 markers.py:115(_recache)
 38 7.378 0.194 7.378 0.194 {gc.collect}
 13564851 6.768 0.000 6.768 0.000 {isinstance}
I1 run -p test_speed3.py
 61658708 function calls (60685172 primitive calls) in 100.934 seconds
 Ordered by: internal time
 ncalls tottime percall cumtime percall filename:lineno(function)
 937414 6.638 0.000 6.638 0.000 {numpy.core.multiarray.array}
 374227 4.377 0.000 7.500 0.000 path.py:198(iter_segments)
 6974613 3.866 0.000 3.866 0.000 {getattr}
 542640 3.809 0.000 7.900 0.000 core.py:2749(_update_from)
 141361 3.665 0.000 7.136 0.000 transforms.py:99(invalidate)
324688/161136 2.780 0.000 27.747 0.000
transforms.py:1729(transform)
 64448 2.753 0.000 64.921 0.001 lines.py:463(draw)
 231195 2.748 0.000 7.072 0.000 path.py:86(__init__)
684970/679449 2.679 0.000 3.888 0.000
backend_pdf.py:128(pdfRepr)
 67526 2.651 0.000 7.522 0.000
backend_pdf.py:1226(pathOperations)
-- 
Gökhan

>
> And you might get back more memory if you didn't have to have all the data
> in memory at once, but that may or may not help you. The only other
> suggestion I can make is to attempt to eliminate the overhead in the inner
> loop. Essentially, I would try making a single figure and a single
> AxesGrid object (before the outer loop). Then go over each subplot in the
> AxesGrid object and set the limits, the log scale, the ticks and the tick
> locater (I wouldn't be surprised if that is eating up cpu cycles). All of
> this would be done once before the loop you have right now. Then create
> the PdfPages object, and loop over all of the plots you have, essentially
> recycling the figure and AxesGrid object.
>
> At end of the outer loop, instead of closing the figure, you should call
> "remove()" for each plot element you made. Essentially, as you loop over
> the inner loop, save the output of the plot() call to a list, and then when
> done with those plots, pop each element of that list and call "remove()" to
> take it out of the subplot. This will let the subplot axes retain the
> properties you set earlier.
>
> I hope that made sense.
> Ben Root
>
>
Hi Ben,
I should have data the available at once, as I directly read that array
from a netcdf file. The memory requirement for my data is small comparing
to overhead added once plot creation is started. Fabrice's reply includes
most of what you describe except the remove call part. These changes made
big impact to lower my execution times. Thank you again for your
explanation.
-- 
Gökhan