matplotlib-users Mailing List for matplotlib (Page 7)

Peter Groszkowski wrote:
> I use Hardy's multiquadric interpolation to to do the math,  then use 
> imshow (or pcolor) to make a surface map.  I only have data for the 120 
> points (where the circle are - those are actuators), and interpolate the 
> rest.
> 
> If people are interested, I can clean up the code a little and post it.

Please do.



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Perry Greenfield wrote:

>
> On Dec 9, 2004, at 2:12 PM, Chris Barker wrote:
>
>> LUK ShunTim wrote:
>>
>>> As it's being implemented, here is a little wish. I'd like to see 
>>> the capability of contouring on an arbitrary grid. That is, 
>>> matplotlab would be able to plot the contours of a function f(x_i, 
>>> y_i) given on an arbitrary set of points (x_i, y_i), not necessarily 
>>> set out on a regular grid.
>>
>>
>> This would be nice, but it's a bit of a project. One way to do it 
>> would be to Delaunay triangulate the points, then you can compute the 
>> contours from the triangular grid. Delaunay triangulation is not 
>> trivial, and you really want to use an efficient scheme to do it. One 
>> possibility is:
>>
>> http://www-2.cs.cmu.edu/~quake/triangle.html
>>
>> It is very robust and fast, and can be compiled as a library. I've 
>> been planning for ages to write a Python wrapper for it, but haven't 
>> gotten to it yet.
>>
>> If someone works on this, I'd like to help.
>>
>> -Chris
>>
>
> Actually, I believe that the low level contour engine we are using
> supports this. It takes 2-d arrays for both x and y that represent
> the x and y coordinates of the array being contoured and generates
> plotting points based on those x and y arrays. These arrays allow
> for irregular grids. At the moment, the routine generates uniform
> x and y grids as arguments to pass along, but it could be generalized
> to take these as extra arguments without much trouble.


I use Hardy's multiquadric interpolation to to do the math,  then use 
imshow (or pcolor) to make a surface map.  I only have data for the 120 
points (where the circle are - those are actuators), and interpolate the 
rest.

If people are interested, I can clean up the code a little and post it.

Hi,

I'm doing relatively simple line plots the WXAgg backend, but I
also find matplotlib to be somewhat slower than I'd hope for.

On a WindowsXP box (P4 1.7GHz, 512Mb RAM), in a wx event loop
issuing a plot() as fast as I can go, I get about 1 plot every
0.25 to 0.30 sec.  This is just barely fast enough for my needs.  
If I could reliably go at 10 plots/sec, that would be great.

It turns out that the dynamic_demo_wx.py example does go much
faster, but it does not actually re-do a plot(). Instead it just
changes the subplots line data.  That's interesting, but I need
the view to be adjusted as well, as the scale will change with
time for my data.  So far, I'm just re-issuing plot(), but I'd be
willing to do something slightly fancier.

Anyway, that led me to try to track down where the slowness in
plot() was coming from. Using nothing more sophisticated than
print statements, I believe the performance bottleneck is in
axis.py in Axis.draw(), in this block:

        for tick, loc, label in zip(majorTicks, majorLocs, majorLabels):
            if not interval.contains(loc): continue
            seen[loc] = 1
            tick.update_position(loc)
            tick.set_label1(label)
            tick.set_label2(label)            
            tick.draw(renderer)
            extent = tick.label1.get_window_extent(renderer) 
            ticklabelBoxes.append(extent)

For me, this block (run twice for a plot()) typically takes at
least 50% of the plot time.  Commenting out the
tick.draw(renderer) and the following two 'extent' lines roughly
doubles the drawing rate (though no grid or ticks are shown). I
was surprised by this, but have not tracked it down much beyond
this.  I'm not using mathtext in the labels and had only standard
numerical Tick labels in this example.

I don't know if this is applicable to the slowness of the contour
plots or error bars or if collections would help here.  But it
doesn't seem like tick drawing should be the bottleneck. Anyway,
this seems like a simple place to test in other situations, and
may be a good place to look for possible optimizations.

Thanks, 

--Matt

On Dec 9, 2004, at 2:33 PM, Perry Greenfield wrote:
>
> Actually, I believe that the low level contour engine we are using
> supports this. It takes 2-d arrays for both x and y that represent
> the x and y coordinates of the array being contoured and generates
> plotting points based on those x and y arrays. These arrays allow
> for irregular grids. At the moment, the routine generates uniform
> x and y grids as arguments to pass along, but it could be generalized
> to take these as extra arguments without much trouble.
>
> Let me know if I misunderstand what you are trying to do.
>
> Perry
>
Correction. It already supports that feature now (but it isn't
checked in yet).

On Dec 9, 2004, at 2:12 PM, Chris Barker wrote:

> LUK ShunTim wrote:
>> As it's being implemented, here is a little wish. I'd like to see the 
>> capability of contouring on an arbitrary grid. That is, matplotlab 
>> would be able to plot the contours of a function f(x_i, y_i) given on 
>> an arbitrary set of points (x_i, y_i), not necessarily set out on a 
>> regular grid.
>
> This would be nice, but it's a bit of a project. One way to do it 
> would be to Delaunay triangulate the points, then you can compute the 
> contours from the triangular grid. Delaunay triangulation is not 
> trivial, and you really want to use an efficient scheme to do it. One 
> possibility is:
>
> http://www-2.cs.cmu.edu/~quake/triangle.html
>
> It is very robust and fast, and can be compiled as a library. I've 
> been planning for ages to write a Python wrapper for it, but haven't 
> gotten to it yet.
>
> If someone works on this, I'd like to help.
>
> -Chris
>

Actually, I believe that the low level contour engine we are using
supports this. It takes 2-d arrays for both x and y that represent
the x and y coordinates of the array being contoured and generates
plotting points based on those x and y arrays. These arrays allow
for irregular grids. At the moment, the routine generates uniform
x and y grids as arguments to pass along, but it could be generalized
to take these as extra arguments without much trouble.

Let me know if I misunderstand what you are trying to do.

Perry

Arnd Baecker wrote:
> P.S.: I agree on the speed issues. Unfortunately
>       most of the newer python graphics packages tend to be
>       slower than older packages.

I think this has two reasons:

1) They are written more in Python, rather than wrapping an existing 
library written in C or whatever.

2) They often are back-end independent. This introduces an extra layer 
at every drawing command, and makes it difficult to take advantage of 
possible optimizations available for a given back end, like Arnd has 
done for his stuff.

One thing that could help here is if all the drawing commands were 
"vectorized". This would mean that rather than asking the back-end to 
draw one primitive at a time, a whole set could be passed in. This would 
allow the back end to possibly optimize the drawing of the set. An 
example is wxPython's DC.DrawXXXList() methods. These methods take a 
python sequence of drawing primitives, and loop through that sequence in 
C++ code. It makes a huge difference when drawing simple objects, like 
points or line segments.

I haven't looked closely at the matplotlib code to see if this can be 
done, but it could make a difference.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

LUK ShunTim wrote:
> As it's being implemented, here is a little wish. I'd like to see the 
> capability of contouring on an arbitrary grid. That is, matplotlab would 
> be able to plot the contours of a function f(x_i, y_i) given on an 
> arbitrary set of points (x_i, y_i), not necessarily set out on a regular 
> grid.

This would be nice, but it's a bit of a project. One way to do it would 
be to Delaunay triangulate the points, then you can compute the contours 
from the triangular grid. Delaunay triangulation is not trivial, and you 
really want to use an efficient scheme to do it. One possibility is:

http://www-2.cs.cmu.edu/~quake/triangle.html

It is very robust and fast, and can be compiled as a library. I've been 
planning for ages to write a Python wrapper for it, but haven't gotten 
to it yet.

If someone works on this, I'd like to help.

-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Am Donnerstag, 9. Dezember 2004 17:38 schrieb John Hunter:
> Note it
> would be possible to define setitem, getitem, and possibly setslice,
> getslice and iter for collections to make them behave more like lists
> of objects, which would be nice if we (you) want to make this change.

Would that be possible at all? Do individual items in a collection have an 
identity at all that could be exposed in Python? Do they have individual 
properties?

Note, that I probably won't have the time to look into this matter myself. 
Maybe one day, but certainly not in the near future.

Ciao,
Nobbi

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

Hi,

1. slow plot
2. cursor issue
3. key press event !
-------
1/ 

Here is the piece of code which is quite slow I think. Compared to 
pgplot this
is a factor of more than 10. It does first draw a default plot (0,1 ?) 
and then
overplot on it for each subplot.

for this particular case I have 10 subplots. The slices are made of 
about 10-20
points each only (stored in a 3D array which is  48x5x20 points).
I hope this answers the question. Sorry for the ''specifics''.

        for i in arange(ncoef) :
           subplot(nrow, 2, i+1)
           if i > 1 :
              temparray = self.Vcoef[indgal][i][:minind] / 
self.Vcoef[indgal][1][:minind]
              plot(self.Vrad[indgal][:minind], temparray, 'b-o', ms=4)
           else :
              plot(self.Vrad[indgal][:minind], 
self.Vcoef[indgal][i][:minind], 'b-o', ms=4)
           ylabel('$C_{%d'%i+'}$')

        for i in arange(ncoef) :
           j = i + ncoef
           subplot(nrow, 2, j+1)
           plot(self.Vrad[indgal][:minind], 
self.Vphi[indgal][i][:minind], 'b-o', ms=4)
           ylabel('$\phi_{%d'%i+'}$')

2/ the cursor issue and how to interact with it:
yes indeed the solution I took is close to what is shown in some examples.
I used a new class which I then use later on in interactive mode or not.
Below is a simple/shortened example of the structure I create by just 
transferring
the data (x,y,key, etc) to the cursor structure. I can then use : toto = 
cursor()
to have it working. (I in fact define several different cursor_* classes 
for different purposes).
So sorry if my mail sounded like ''I have found a new way...''.

class cursor :
   def __init__(self):
      print 'Class initialized'
      self.figure = Figure()
      self.canvas = get_current_fig_manager().canvas
      self.canvas.mpl_connect('button_press_event', self.on_click)
      self.x = 0
      self.y = 0
      self.button = 1

   def on_click(self, event):
      self.x = event.x
      self.y = event.y
      self.xd = event.xdata
      self.yd = event.ydata
      self.button = event.button
      ...

3/ key press event

>Currently key_press_event is not implemented (though mouse move and
>motion to capture and report key presses as event.key).  We added this
>because this is how we do the event handling across backends for the
>toolbar.  There are also some fixes in CVS to make disconnects work
>properly, eg in the tk backend.
>
>It would be fairly straightforward to add a key_press_event under the
>same framework.
>
>  
>
That WOULD be great since this is exactly what I needed. For example being
able to type ''h'' to make an horizontal cut of my image at the location 
corresponding
to the mouse position.... I do that easily with ppgplot for example.

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:

    Eric> P.S.: by the way I solved the cursor problem I posted (and
    Eric> got no answer) by defining a new cursor class (something
    Eric> already hinted by many on the web), if anyone is
    Eric> interested..

Been out of town at meetings for the last week...

Have you seen
http://matplotlib.sourceforge.net/examples/coords_demo.py, which shows
how to connect to mouse motion and click?  The interface is being
streamlined in 0.65.  Ie in CVS, one simply needs to do

  def on_click(event): pass
  connect('button_press_event', on_click)

Currently key_press_event is not implemented (though mouse move and
motion to capture and report key presses as event.key).  We added this
because this is how we do the event handling across backends for the
toolbar.  There are also some fixes in CVS to make disconnects work
properly, eg in the tk backend.

It would be fairly straightforward to add a key_press_event under the
same framework.

For "cursoring", see the *cursor*.py examples in the examples subdir
of the matplotlib src distro.

But please also post your solution which may be useful....

JDH

>>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:

    Norbert> I have experienced some extreme inefficiency using
    Norbert> errorbar plots for large datasets. Obviously, the
    Norbert> "hlines" routine is a huge bottleneck. Would it be
    Norbert> possible, in principle, to use an efficient collection
    Norbert> instead?
As Perry noted, it would be nice to see some of Eric's code to see if
this is the kind of bottleneck he is bumping into.

It would be very straightforward to use collections here is what they
were designed for - removing bottlenecks created by instantiating many
similar objects.  I've never plotted a large number of errorbar lines
so haven't bumped into this one.

Note this might break some code which is relying on the fact that the
errorbar routing is returning a list of errorbar lines.  collections
are designed to respond similarly to lists of lines under the set
command.  Eg

  set(lines, color='r', linewidth=4)

and 

  set(collection, color='r', linewidth=4)

will both work.

But if someone is currently doing 

  lines[2].set_color('g')

or

  for line in lines:
      line.set_something(else)

there would be a backward incompatibility with this change.  Note it
would be possible to define setitem, getitem, and possibly setslice,
getslice and iter for collections to make them behave more like lists
of objects, which would be nice if we (you) want to make this change.

Is anyone changing the properties of individual error lines returned
by errorbar?

JDH

Am Mittwoch, 8. Dezember 2004 16:35 schrieb Perry Greenfield:
> Could you give some indication of what speed you are getting vs what you
> have gotten under other plotting packages?

I have experienced some extreme inefficiency using errorbar plots for large 
datasets. Obviously, the "hlines" routine is a huge bottleneck. Would it be 
possible, in principle, to use an efficient collection instead?

-- 
_________________________________________Norbert Nemec
         Bernhardstr. 2 ... D-93053 Regensburg
     Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
           eMail: <No...@Ne...>

Perry Greenfield wrote:
> 
> On Dec 8, 2004, at 3:29 AM, Eric Emsellem wrote:
> 
>> Hi,
>>
>> I am now trying to switch from ppgplot to matplotlib and I
>> really like the latter for the much nicer plots and functionalities
>> (although limitations such as the absence of contour plots is a 
>> critical one).
> 
> 
> There is progress being made on contour plots. We've implemented a basic
> version that John Hunter is looking at now.
> 

It's really nice to hear that. As Eric said, it's one thing that is 
sorely missed.

As it's being implemented, here is a little wish. I'd like to see the 
capability of contouring on an arbitrary grid. That is, matplotlab would 
be able to plot the contours of a function f(x_i, y_i) given on an 
arbitrary set of points (x_i, y_i), not necessarily set out on a regular 
grid.

Regards,
ST
--

Delbert D. Franz writes:
 > I am evaluating matplotlib for its date handling for plotting time 
 > series produced by a unsteady-flow simulation package.  
 > I downloaded the Debian package from http://anakonda.altervista.org/debian
 > because I could not get apt-get to get the package after modifying
 > my sources.list.  

This problem went away for me when I upgraded

to date-util to version 0.5
https://moin.conectiva.com.br/DateUtil#head-f5cbdf6bfb51439be085b5c6b7460a7c91eabc3c

-- Phil

I am evaluating matplotlib for its date handling for plotting time 
series produced by a unsteady-flow simulation package.  
I downloaded the Debian package from http://anakonda.altervista.org/debian
because I could not get apt-get to get the package after modifying
my sources.list.  

However, dpkg did not complain about any missing packages and 
several test cases worked well.  However, none of the following 
examples would run

date_demo1.py  
    error---cannot import date2num, num2date

date_demo2.py
    error--cannot import name MONDAY

date_demo_convert.py
    error--cannot import DayLocator, HourLocator

date_demo_rrule.py
    error--cannot import name YEARLY

After some time checking docs and looking at the various
*.py files involved, I noticed that none of the dateutl files 
were on my system and neither were the pytz files.  
The documentation on the web site clearly states that 
the dateutil files are included in the package but somehow 
they got missed in the 0.64-1 release downloaded from the
site given above.  

After downloading and installing these two packages all 
but date_demo_rrule.py completed properly.  
The error in this case was an unknown name "rand".
A check of the Python Library reference stated it was
obsolete.  I replaced it with random.randrange but 
got another error, an assertion error apparently on 
the y value.  Being somewhat new to Python and 
even newer to matplotlib I gave up on that demo. 

Perhaps someone else can test date_demo_rrule.py
and see what happens.  It is always a good thing when
demos in fact run!

I am also testing under MS Windows and the dateutils
and pytz files came with that install but none of the 
example files came.  Not sure why they are not 
included in the *.exe installer. 

I am using Python 2.3.4
matplotlib   0.64-1
Libranet 2.8.1
Kernel 2.6.9

                                      Delbert Franz 

       Hello,

I have a problem to plot some data.

I use "plot" to plot some data and "scatter" for other. I obtain a plot 
whith the point trace with "scatter" are behind the points from "plot". 
I tried to change the order in the script but that change nothing.
Do you know how to do this? (I want use scatter because I want have a 
specific size for this points)

Thanks,

    Nicolas

To whomever manages the Debian packages for matplotlib:

Recently (past month), I've been getting an Ign from apt-get update for
the Debian package of Matplotlib.  Has the URL changed?

Cheers,
Curtis



      * * * * * * * * * * * * * * * * * * * * * * * * * * * *
    *   Curtis S. Cooper, Graduate Research Assistant         *
   *    Lunar and Planetary Laboratory, University of Arizona  *
   *    http://www.lpl.arizona.edu/~curtis/		       *
   *    Kuiper Space Sciences, Rm. 318                         *
    *   1629 E. University Blvd.,                             *
     *  Tucson, AZ 85721        * * * * * * * * * * * * * * *
      * Wk: (520) 621-1471     *
       * * * * * * * * * * * *

On Dec 8, 2004, at 3:29 AM, Eric Emsellem wrote:

> Hi,
>
> I am now trying to switch from ppgplot to matplotlib and I
> really like the latter for the much nicer plots and functionalities
> (although limitations such as the absence of contour plots is a 
> critical one).

There is progress being made on contour plots. We've implemented a basic
version that John Hunter is looking at now.
>
> However, I just made a small script to plot 10 small subplots
> on a single window repeatedly (going through slices of an array each 
> time)
> and it is bloody slooooooooow (a very large factor slower than anything
> I can use to do the same thing with python and some graphical 
> functions).
>
> I personnally think this is a major limitation (with the contours) of
> that piece of soft, and may discourage many (and myself).
>
Could you give some indication of what speed you are getting vs what you
have gotten under other plotting packages? How big is the slice (how 
many
points)? What kind of plot? Showing the actual script may help a lot in
understanding why it is so slow. There may be other ways that are 
faster,
or it will at least point to the main bottleneck that could stand 
improvement.
This complaint is too general to be helpful. I'm not sure it should be
matplotlib's goal to be the fastest package around, but it should be
fast enough for ordinary plotting (which means different things to
different people of course).

> Is there a way to improve (dramatically) this? Is there a plan there?
>
> thanks in advance,
>
> Eric Emsellem
>
> P.S.: by the way I solved the cursor problem I posted (and got no 
> answer)
> by defining a new cursor class (something already hinted
> by many on the web), if anyone is interested..
>
I missed this post (I'm too busy at the moment to read all posts).
Yes, having this functionality is important. Some of this is possible
now but John has this at his fingertips (I can't recall the details).
If I have time I'll see if I can dig this up.

Perry

hello,

i was enjoying using matplotlib... until i installed gnome-python-2.6.1. now, when i do something simple like:

>>> figure(1)

the interpreter hangs up for AGES. with verbose matplotlib output, the place at which it hangs is here:

Value::~Value
Value::~Value
Point::~Point
Value::~Value
Value::~Value
Bbox::~Bbox
Point::~Point
Value::~Value
Value::~Value
Point::~Point
Value::~Value
Value::~Value
Transformation::~Transformation
<HERE>

eventually i get back to the prompt. has anyone else experienced this incompatibility?

cheers,
andrew.

-- 
Andrew B. Collier

Antarctic Research Fellow                                   tel: +27 31 2601157
Space Physics Research Institute                            fax: +27 31 2616550
University of KwaZulu-Natal, Durban, 4041, South Africa

Hi Eric,

On Wed, 8 Dec 2004, Eric Emsellem wrote:

[...]

> P.S.: by the way I solved the cursor problem I posted (and got no answer)
> by defining a new cursor class (something already hinted
> by many on the web), if anyone is interested..

I would be very interested in this - maybe you could
post it here (also for the archive ;-).
If possible it would be nice to see this integrated into matplotlib
because this sounds like a replacement of scipy.xplt/pygist's
mouse command (or ppgplot's pgband?).

Best,

Arnd


P.S.: I agree on the speed issues. Unfortunately
      most of the newer python graphics packages tend to be
      slower than older packages.
      For example scipy.xplt (aka pygist) see
      http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/index.html
      is reasonably fast.

      We have set up a PlottingCanvas for wxPython
      for our specific needs of fast plotting of single points
      and moving objects,
        http://www.physik.tu-dresden.de/~baecker/python/plot.html
      But this is by far not a fully featured plotting program,
      though maybe some of the ideas used there to speed
      up things could be used in matplotlib
      (note that I state this with complete ignorance
      of matplotlib's interna).

Hi,

I am now trying to switch from ppgplot to matplotlib and I
really like the latter for the much nicer plots and functionalities
(although limitations such as the absence of contour plots is a critical 
one).

However, I just made a small script to plot 10 small subplots
on a single window repeatedly (going through slices of an array each time)
and it is bloody slooooooooow (a very large factor slower than anything
I can use to do the same thing with python and some graphical functions).

I personnally think this is a major limitation (with the contours) of
that piece of soft, and may discourage many (and myself).

Is there a way to improve (dramatically) this? Is there a plan there?

thanks in advance,

Eric Emsellem

P.S.: by the way I solved the cursor problem I posted (and got no answer)
by defining a new cursor class (something already hinted
by many on the web), if anyone is interested..

-- 
===============================================================
Observatoire de Lyon                 ems...@ob...
9 av. Charles-Andre                      tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex            fax: +33 4 78 86 83 86
France               http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

>>>>> "Norm" == Norm Petterson <nj...@nj...> writes:


    Norm> If anyone is interested in my modified backend_svg.py please
    Norm> let me know where to send it.

You can send it to me directly offlist and I'll merge it into the main
tree.  Just make sure to put matplotlib in the subject header to get
past my spam filter...

Thanks!
JDH

Hello,

I've just encountered the same situation with SVG rendering where I =
repeatedly generate a changed SVG plot and only the first time does it =
render properly. I traced the problem to the SVG renderer failing to =
include "ClipPath" information in generated SVG files after the first =
one, and fixed it in my case by changing backend_svg.RendererSVG to deal =
with _clipd as self._clipd in both its __init__ method (i.e., =
initialized to {}) and its _get_gc_clip_svg method (i.e., _clipd  =
changed to self._clipd). Just before RendererSVG is defined, _clipd is =
declared as a module-scope entity, and this is the problem, so comment =
it out...

If anyone is interested in my modified backend_svg.py please let me know =
where to send it.

Regards,

Norm Petterson

  ----- Original Message -----=20
  From: Haibao Tang=20
  To: mat...@li...=20
  Sent: Monday, December 06, 2004 4:55 PM
  Subject: [Matplotlib-users] [Possible BUG:] SVG renderer;


  Hi, I've run into a problem using matplotlib renderer to generate =
files. My example is huge, so I implement it in another way to give the =
idea.
  - o - o - o - o - o - o - o - o - o - o - o - o - o - o=20
  from matplotlib.matlab import *

  def draw_box(i):
      root =3D axes([0,0,1,1])
      root.bar(.2,.5,.5,.2)
      root.text(.2, .1, "Give me a box %02i"%i)
      xlim(0,1)
      ylim(0,1)
      savefig("c:\\svg\\%02i.svg"%i)

  for i in xrange(1,10):
      clf()
      draw_box(i)
  - o - o - o - o - o - o - o - o - o - o - o - o - o - o=20

  The resulting files are generated, yet except the first one, all the =
rest miss the bar();
  BUT, if I change the format to .png, no problem exists.

  Is it a bug? or am I doing it right?
  Much appreciated if you can point the problem out.

  Bao

Hi, I've run into a problem using matplotlib renderer to generate files. =
My example is huge, so I implement it in another way to give the idea.
- o - o - o - o - o - o - o - o - o - o - o - o - o - o=20
from matplotlib.matlab import *

def draw_box(i):
    root =3D axes([0,0,1,1])
    root.bar(.2,.5,.5,.2)
    root.text(.2, .1, "Give me a box %02i"%i)
    xlim(0,1)
    ylim(0,1)
    savefig("c:\\svg\\%02i.svg"%i)

for i in xrange(1,10):
    clf()
    draw_box(i)
- o - o - o - o - o - o - o - o - o - o - o - o - o - o=20

The resulting files are generated, yet except the first one, all the =
rest miss the bar();
BUT, if I change the format to .png, no problem exists.

Is it a bug? or am I doing it right?
Much appreciated if you can point the problem out.

Bao

>>>>> "Niklas" == Niklas Volbers <Mit...@we...> writes:

    Niklas> Hello, I am using the class interface to mpl and I was
    Niklas> wondering if it is an intended behaviour, that you cannot
    Niklas> set the label to 'None'.  Using:

    Niklas> Axes.set_xlabel(None)

Axes.set_xlabel('')

JDH