matplotlib-users Mailing List for matplotlib (Page 6)

>>>>> "Alan" == Alan G Isaac <ai...@am...> writes:

    Alan> Aside from my wishes, should the script fail in this fashion
    Alan> (rather than being more gracefully rejected)?  I realize we
    Alan> have been warned against using show() multiple times ...

We've taken pains to protect against multiple calls to show.  If you
can provide a script which replicates the problem.  Please test
against the latest matplotlib, preferably the next release, due out
tomorrow barring the unexpected (which is never expected).

    Alan> Somewhat related: can I control the order in which figures
    Alan> are displayed when the show() command is given, or will the
    Alan> highest numbered figure always display on top?

This may be backend dependent, I haven't tested it.  But if it is the
highest figure on top you should be in good shape, right?, because you
can provide the figure numbers in the order you want the figures
to appear, bottom to top.

JDH

>>>>> "Uwe" == Uwe Hoffmann <qu...@ti...> writes:

    Uwe> Hi, i am using the simple_plot.py example with the Agg or
    Uwe> WXAgg backends.  If i insert the following line:
    Uwe> rcParams["figure.facecolor"] = "r" the background is red when
    Uwe> using the WXAgg driver but with the Agg backend the
    Uwe> background of the png image is still white.

    Uwe> Any hints ?  (matplotlib 0.64, linux)

help(savefig)

The default figure facecolor is passed as a kwarg in savefig.  The
idea is that you often want a different background color for the
figure in a GUI (eg gray) and in hardcopy (eg white)

  savefig('myfile', facecolor='r') 

should work.

JDH

Hi,

i am  using the simple_plot.py example with the Agg or WXAgg backends.
If i insert the following line:
rcParams["figure.facecolor"] = "r"
the background is red when using the WXAgg driver but with the Agg 
backend the background of the png image is still white.

Any hints ?
(matplotlib 0.64, linux)

greetings
	Uwe

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> In thinking about the ioff(), ion() approach it occurs to
    Perry> me that it may not be quite so simple for scripts. I think
    Perry> a common desire is for a script or function to turn off
    Perry> interactive mode if it is on, but at the end, restore the
    Perry> previous interactive state. In this case a push/pop
    Perry> approach to interactive mode may be more appropriate rather
    Perry> than stop/start. In particular, if interactive mode
    Perry> happended to be off, you wouldn't want to turn it on at the
    Perry> end of the script.

BTW, Eric emailed me off list.  It appears that running his script in
interactive mode was the root cause of his performance problems.

In regards to running scripts from the python shell, I think the least
invasive approach is to write a run function that stores the
interactive state, calls ioff, runs the script with execfile, then
calls ion (precisely what ipython does).  In fact, perhaps we should
add a run function to the pylab interface which does just this.
Fernando could simply override this function if he wants to do some
additional ipython magic.  But this would wrap the logic for those who
want to run scripts from the other python shell.  Of course it would
only work for non-image backends and Tk, or GUI backends associated
with a GUI shell like pycrust.

I'm less worried about people inadvertently running scripts from the
command shell with interactive set to True, because interactive
defaults to False in rc and thus the person would have had to
intentionally change it, at least at some point in dark history.
Hence they are probably aware of it.  Singing the praises of ipython
yet again, I leave the default in my rc to False, and run ipython when
I want to work interactively, letting ipython turn interaction on for
me. Thus I can run python somescript.py from the command shell assured
that it is off, and still use matplotlib interactively w/o having to
tweak the setting.  

But if there is some concern for users who would like to leave
interactive on in rc (eg they like to use the standard python shell or
some other shell) and still be able to get the efficiency when running
scripts from the command shell, it might be possible to inspect
whether we are in a running in a python shell, and plug this
additional information into draw_if_interactive.  Something like

def draw_if_interactive():
    if running_in_python_shell() and matplotlib.is_interactive():
       canvas.draw()

Anyone know how to determine whether you are running code in a python
shell versus running a script, eg from a command shell?

It occurs to me that "interactive" is not really the best name for
this matplotlib state.  Really we want something that conveys
"draw_after_every_plot_command".  When I named it, I was assuming that
when working interactively you would want to update with every plot
command, but have learned that this is not always the case.  Do you
think it's worth coming up with new names (isdraw(),
draw_always(True/False), etc, while preserving the old names for a
while with deprecation)?  Because that's what we're really doing,
controlling the drawing.

JDH

In thinking about the ioff(), ion() approach it occurs to me that
it may not be quite so simple for scripts. I think a common 
desire is for a script or function to turn off interactive mode
if it is on, but at the end, restore the previous interactive 
state. In this case a push/pop approach to interactive mode may
be more appropriate rather than stop/start. In particular, if 
interactive mode happended to be off, you wouldn't want to turn
it on at the end of the script.

Perry

John Hunter wrote:
[...]
> 
> By default, matplotlib defers drawing until the end of the script
> because drawing can be an expensive opertation, and you may not
> want to update the plot every time a single property is changed, only
> once after all the properties have changed.
> 
> But in interactive mode, eg from the python shell, you usually do want
> to update the plot with every command, eg, after changing the xlabel
> or the marker style of a line.  With the TkAgg backend, you can use
> matplotlib from an arbitrary python shell.  Just set TkAgg to be your
> default backend and interactive to be True in your matplotlibrc file
> and fire up python.  Then
> 
> >>> from pylab import *
> >>> plot([1,2,3])
> >>> xlabel('hi mom')
> 
> should work out of the box.  Note, in batch mode, ie when making
> figures from scripts, interactive mode can be slow since it redraws
> the figure with each command.  So you may want to think carefully
> before making this the default behavior.  TkAgg sets interactive mode
> to True when you issue the show command.
> 
[...]

I'd just add that we may want to recommend that using ioff(), ion()
be part of the matplotlib idiom for writing demos and larger, more
involved plotting programs and scripts particularly where the 
author of the script or function is unsure of what context it
will be run in. That way it always runs efficiently. Does that
seem a reasonable thing to recommend?

Perry

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> John Hunter Wrote:>
    >> Aside from the aforementioned "run" mode of ipython, which does
    >> just this, the basic incantation is
    >> 
    >> >>> from matplotlib import interactive, is_interactive >>> b =
    >> is_interactive() # store the current interactive state >>>
    >> plot(blah, blah) # make some plots >>> interactive(False) #
    >> turn interactive off >>> for i in arange(1e4096):
    >> plot(arange(i), arange(i)**2) # don't try this at home >>>
    >> interactive(b) # restore previous interactive state
    >> 
    >> Basically, this is what ipython does.  This is wrapped into a
    >> single function "run", called like
    >> 
    >> >>> x = 1 # some fluff >>> run ~/myexamples/simple_demo.py #
    >> turn interactive off for run >>> x = 2 # interactive setting is
    >> restored
    >> 
    >> But of course, you can use the interactive / is_interactive
    >> functions in any script or interactive session.
    >> 
    >> To make this more accessible, perhaps we should add an
    >> interactive (or update) kwarg to plot and friends, in the same
    >> vein that we discussed a kwarg for hold, so you can easily do
    >> things like
    >> 
    >> plot(x, y, hold=False) # add plot, clearing previous plot(x, y,
    >> update=False) # add plot but do not update
    >> 
    >> But the question arises, does the additional complexity in the
    >> matplotlib internals required to support this justify the
    >> savings for the occasional user who would otherwise have to
    >> type a couple of extra lines?
    >> 
    Perry> In this case I don't think so. the function interactive()
    Perry> is what I was looking for, not a keyword argument. Unlike
    Perry> overplotting, I think interactive() is likely to be used
    Perry> almost entirely in scripts and functions and that is by far
    Perry> the better approach.  So it's already good enough as far as
    Perry> I'm concerned.

Following these discussions, I just added ion and ioff to the pylab
interface, and updated the web site interaction page with (not
uploaded yet) with the following.  Let me know if you have anything to
add here.

By default, matplotlib defers drawing until the end of the script
because drawing can be an expensive opertation, and you may not
want to update the plot every time a single property is changed, only
once after all the properties have changed.

But in interactive mode, eg from the python shell, you usually do want
to update the plot with every command, eg, after changing the xlabel
or the marker style of a line.  With the TkAgg backend, you can use
matplotlib from an arbitrary python shell.  Just set TkAgg to be your
default backend and interactive to be True in your matplotlibrc file
and fire up python.  Then

>>> from pylab import *
>>> plot([1,2,3])
>>> xlabel('hi mom')

should work out of the box.  Note, in batch mode, ie when making
figures from scripts, interactive mode can be slow since it redraws
the figure with each command.  So you may want to think carefully
before making this the default behavior.  TkAgg sets interactive mode
to True when you issue the show command.

Unfortunately, due to the 'mainloop' cycle of GUI toolkits, it is not
yet possible to use matplotlib from an arbitrary python shell with the
other GUI backends.  You must use a custom python shell that runs the
GUI is a separate thread.

The recommended way to use matplotlib interactively from a shell is
with ipython, which has an pylab mode that detects your matplotlib
.matplotlibrc file and makes the right settings to run matplotlib with
your GUI of choice in interactive mode using threading.  gtk users
will need to make sure that they have compiled gtk with threading for
this to work.  Using ipython in pylab mode is basically a nobrainer
because it knows enough about matplotlib internals to make all the
right settings for you internally

  peds-pc311:~> ipython -pylab
  Python 2.3.3 (#2, Apr 13 2004, 17:41:29) 
  Type "copyright", "credits" or "license" for more information.

  IPython 0.6.5 -- An enhanced Interactive Python.
  ?       -> Introduction to IPython's features.
  %magic  -> Information about IPython's 'magic' % functions.
  help    -> Python's own help system.
  object? -> Details about 'object'. ?object also works, ?? prints more.

  Welcome to pylab, a matplotlib-based Python environment.
    help(matplotlib) -> generic matplotlib information.
    help(matlab)     -> matlab-compatible commands from matplotlib.
    help(plotting)   -> plotting commands.

  >>> plot( rand(20), rand(20), 'go' )

Note that you did not need to import any matplotlib names because in
pylab mode ipython will import them for you.  ipython turns on
interactive mode for you, and also provides a "run" command so you can
run matplotlib scripts from the matplotlib shell and then
interactively update your figure.  ipython will turn off interactive
mode during a run command for efficiency, and then restore the
interactive state at the end of the run.

  >>> cd python/projects/matplotlib/examples/
  /home/jdhunter/python/projects/matplotlib/examples
  >>> run simple_plot.py
  >>> title('a new title', color='r')

The pylab interface provides 4 commands that are useful for
interactive control.  Note again that the interactgive setting
primarily controls whether the figure is redrawn with each plotting
command.  is_interactive returns the interactive setting, ion turns
interactive on, ioff turns it off, and draw forces a redraw of the
entire figure.  Thus when working with a big figure in which drawing
is expensive, you may want to turn matplotlib's interactive setting
off temporarily to avoid the performance hit

  >>> run mybigfatfigure.py
  >>> ioff()      # turn updates off
  >>> title('now how much would you pay?')
  >>> xticklabels(fontsize=20, color='green')
  >>> draw()      # force a draw
  >>> savefig('alldone', dpi=300)
  >>> close()
  >>> ion()      # turn updates back on
  >>> plot(rand(20), mfc='g', mec='r', ms=40, mew=4, ls='--', lw=3)

John Hunter Wrote:> 

> Aside from the aforementioned "run" mode of ipython, which does just
> this, the basic incantation is
> 
>   >>> from matplotlib import interactive, is_interactive
>   >>> b = is_interactive()  # store the current interactive state
>   >>> plot(blah, blah)      # make some plots
>   >>> interactive(False)    # turn interactive off
>   >>> for i in arange(1e4096): plot(arange(i), arange(i)**2)  # 
> don't try this at home
>   >>> interactive(b)        # restore previous interactive state
> 
> Basically, this is what ipython does.  This is wrapped into a single
> function "run", called like
> 
>   >>> x = 1                            # some fluff
>   >>> run ~/myexamples/simple_demo.py  # turn interactive off for run
>   >>> x = 2                            # interactive setting is restored
> 
> But of course, you can use the interactive / is_interactive functions
> in any script or interactive session.
> 
> To make this more accessible, perhaps we should add an interactive (or
> update) kwarg to plot and friends, in the same vein that we discussed
> a kwarg for hold, so you can easily do things like
> 
>   plot(x, y, hold=False)    # add plot, clearing previous
>   plot(x, y, update=False)  # add plot but do not update
> 
> But the question arises, does the additional complexity in the
> matplotlib internals required to support this justify the savings for
> the occasional user who would otherwise have to type a couple of extra
> lines?
> 
In this case I don't think so. the function interactive() is what
I was looking for, not a keyword argument. Unlike overplotting,
I think interactive() is likely to be used almost entirely in
scripts and functions and that is by far the better approach.
So it's already good enough as far as I'm concerned.

Perry 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now. 
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

SGkgT3V5YW5nLA0KDQpGaXJzdCBjb25ncmF0dWxhdGlvbnMgb24gZmluZGluZyBtYXRwbG90
bGliLCBpdCBpcyByZWFsbHkgDQp0aGUgYmVzdC1xdWFsaXR5IHB5dGhvbiAyRCBwbG90dGlu
ZyBtb2R1bGUgeW91IGNhbiBmaW5kIG9uIA0KdGhlIHdlYiwgYW5kIHRoZSBwcm9qZWN0IGlz
IGFjdGl2ZSAoZ3JlYXQpLiBJdCBjYW4gdXNlIA0KQ2hpbmVzZSBjaGFyYWN0ZXJzLCBidXQg
bWFrZSBzdXJlIHRoYXQgeW91ciBiYWNrZW5kIERPRVNOJ1QgDQp1c2UgJ0FnZycsIGZvciBl
eGFtcGxlIHRoZSBmb2xsb3dpbmcgY29kZSB3aWxsIHdvcmsgdW5kZXIgLQ0KZFdYLCBidXQg
bm90IC1kV3hBR0c6DQoNCiMgLSotIGNvZGluZzogdXRmLTggLSotIA0KZnJvbSBtYXRwbG90
bGliLm1hdGxhYiBpbXBvcnQgKg0KZm9udCA9IHsnZm9udG5hbWUnICAgOiAnU0lNU1VOJywN
CiAgICAgICAgJ2NvbG9yJyAgICAgIDogJ3InKQ0KcGxvdChbMSwyLDNdLCdidi0nKQ0KdGl0
bGUoIuWkp+WutuWlve+8gSIuZGVjb2RlKCJtYmNzIiksZm9udCkNCnNob3coKQ0KDQpOT1RF
IHRoYXQgdGhpcyByZXF1aXJlcyB5b3VyIHN5c3RlbSB0byBiZSBXSU5ET1dTLWNoaW5lc2UN
Cihvb3BzKSwgb3RoZXJ3aXNlLCB5b3UgaGF2ZSB0byBpbnN0YWxsIHJlbGF0ZWQgY29kZWNz
IHdoaWNoIA0KaSB3aWxsIG5vdCBlbGFib3JhdGUgaGVyZS4gRm9yIHNvbWUgcmVhc29uIHRo
ZSBBZ2cgYmFja2VuZHMgDQpmYWlscyBldmVuIGlmIHlvdSBoYXZlIHRoZSByaWdodCBjb2Rp
bmcsIGluIGxpbmUgMjE5IA0KZ2V0X3RleHRfd2lkdGhfaGVpZ2h0KCksIGl0IHJhaXNlcyBh
biB1bmljb2RlIGVycm9yLiANCg0KRm9yIGEgcGllY2hhcnQsIHlvdSBjYW4gc3RhcnQgd3Jp
dGluZyB5b3VyIG93biwgSkRIIGhhcyANCmFscmVhZHkgZGVmaW5lZCBhbG1vc3QgYWxsIHRo
ZSBjb21wb25lbnRzIGZvciBkb2luZyB0aGlzLCANCmFuZCB5b3UgbWF5IGNvbnRyaWJ1dGUg
eW91ciBjb2RlIHNvbWVkYXk6KSBGb3IgYSBsYXp5IHBlcnNvbiANCmxpa2UgbWUsIEkgdGVt
cG9yYXJpbHkgdXNlIHB5dGhvbiB3cmFwcGVyIGZvciBjaGFydGRpcmVjdG9yLg0KDQpIYWli
YW8gVGFuZw0K

>>>>> "Perry" == Perry Greenfield <pe...@st...> writes:

    Perry> But that made me wonder whether or not there was a need for
    Perry> some sort of switch that delayed any update for just this
    Perry> case where one is looping over many plots (say you wrote a
    Perry> ploting function that did this that you want to run in
    Perry> interactive mode, and you wanted to use basic plotting
    Perry> functions like plot). Is there a simple mechanism to turn
    Perry> off interactive mode temporarily within the function and
    Perry> restore it at the end? If not, could it be added?  (akin to
    Perry> the hold() function)

Aside from the aforementioned "run" mode of ipython, which does just
this, the basic incantation is

  >>> from matplotlib import interactive, is_interactive
  >>> b = is_interactive()  # store the current interactive state
  >>> plot(blah, blah)      # make some plots
  >>> interactive(False)    # turn interactive off
  >>> for i in arange(1e4096): plot(arange(i), arange(i)**2)  # don't try this at home
  >>> interactive(b)        # restore previous interactive state

Basically, this is what ipython does.  This is wrapped into a single
function "run", called like

  >>> x = 1                            # some fluff
  >>> run ~/myexamples/simple_demo.py  # turn interactive off for run
  >>> x = 2                            # interactive setting is restored

But of course, you can use the interactive / is_interactive functions
in any script or interactive session.

To make this more accessible, perhaps we should add an interactive (or
update) kwarg to plot and friends, in the same vein that we discussed
a kwarg for hold, so you can easily do things like

  plot(x, y, hold=False)    # add plot, clearing previous
  plot(x, y, update=False)  # add plot but do not update

But the question arises, does the additional complexity in the
matplotlib internals required to support this justify the savings for
the occasional user who would otherwise have to type a couple of extra
lines?

JDH

Hi everyone,
  I just found matplotlib and like high quality charts
very much. I am wondering if matplotlib support
Chinese Characters? When the pie Chart function will
be added into matplotlib? 

Thanks

Ouyang


		
__________________________________ 
Do you Yahoo!? 
Send holiday email and support a worthy cause. Do good. 
http://celebrity.mail.yahoo.com

John Hunter wrote:

> Plots of this size should be extremely fast - you should be able to
> plot arrays 10 times this big with good performance.  From your
> description "It does first draw a default plot ..and then overplot on
> it for each subplot." it sounds like you may have interactive mode
> turned on.  This would kill your performance in a case like this,
> because the entire figure would be redrawn with the update of every
> single plotting command.  See
> http://matplotlib.sourceforge.net/interactive.html and
> http://matplotlib.sourceforge.net/faq.html#SHOW .
> 
> To definitively determine what mode you are in, run your script with 
> 
>  > python simple_plot.py --verbose-helpful
> 
> and verify that 'interactive is False'.  Fernando Perez's ipython has
> support for running scripts from the interactive shell, turning off
> interactive mode for the duration of the run, and then restoring it.
> 
I wondered the same thing and mentioned that to him privately
(in effect you are doing n*(n-1)/2 plots instead of n).

But that made me wonder whether or not there was a need for some
sort of switch that delayed any update for just this case where
one is looping over many plots (say you wrote a ploting function
that did this that you want to run in interactive mode, and you
wanted to use basic plotting functions like plot). Is there a  
simple mechanism to turn off interactive mode temporarily within
the function and restore it at the end? If not, could it be added?
(akin to the hold() function)

Perry

John Hunter wrote:
>>>>>>"Chris" == Chris Barker <Chr...@no...> writes:
>     Chris> completely irregular? or only orthogonal structured
>     Chris> grids. From your description, it sounds like the
>     Chris> later. Could it take an unstructured set of (x,y,z) points
>     Chris> and contour the z values?
> 
> The latter, I believe.

yup. from the below referenced link:

"""
General purpose contour tracer for quadrilateral meshes.
"""

So it won't handle arbitrary unstructured points, but it's nice none the 
less. With an interpolator to a rectangular grid, you could use it for 
any array of points, I think someone posted an example of this on the 
matplotlib list.

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

John Hunter wrote:

>>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:
>>>>>
>
> Peter> I use Hardy's multiquadric interpolation to to do the math,
> Peter> then use imshow (or pcolor) to make a surface map. I only
> Peter> have data for the 120 points (where the circle are - those
> Peter> are actuators), and interpolate the rest.
>
> Peter> If people are interested, I can clean up the code a little
> Peter> and post it.
>
> This sounds pretty close to matlab's griddata function. 

Yup. That's the functionality I needed. As it says in MATLAB docstrig 
below, GRIDDATA uses Delaunay triangulation however.

> It would be
> very nice to have this in matplotlib.mlab, perhaps as a wrapper to
> some core scipy functionality, which could be conditionally imported.
> What requirements does your code have -- pure python, extension code,
> scipy, numarray?
>
The interpolating is done all in python with the use of Numeric (this is 
what I have been using, and what my matplotlib installation uses - maybe 
will upgrade to numarray one of these days). Performance wise, It's not 
very practical for a very large number of points N as it has to solve a 
NxN system (my N=120 and takes ~2.3seconds on a P4 3.2Ghz with 2GB ram - 
cant remember how long MATLAB's griddata took). Maybe numarray would be 
faster?!

The drawing of the mirror, actuators, etc is done using matplotlibs 
imshow(), plot() and fill() - all very straight forward.

I will post the code in the next few days when I have a minute to clean 
it up a litte.

Cheers,

--
Peter Groszkowski         Gemini Observatory
Tel: +1 808 9742509       670 N. A'ohoku Place
Fax: +1 808 9359235       Hilo, Hawai'i 96720, USA





> Here is the matlab docstring, FYI
>
> GRIDDATA Data gridding and surface fitting.
> ZI = GRIDDATA(X,Y,Z,XI,YI) fits a surface of the form Z = F(X,Y)
> to the data in the (usually) nonuniformly-spaced vectors (X,Y,Z)
> GRIDDATA interpolates this surface at the points specified by
> (XI,YI) to produce ZI. The surface always goes through the data
> points. XI and YI are usually a uniform grid (as produced by
> MESHGRID) and is where GRIDDATA gets its name.
>
> XI can be a row vector, in which case it specifies a matrix with
> constant columns. Similarly, YI can be a column vector and it
> specifies a matrix with constant rows.
>
> [XI,YI,ZI] = GRIDDATA(X,Y,Z,XI,YI) also returns the XI and YI
> formed this way (the results of [XI,YI] = MESHGRID(XI,YI)).
>
> [...] = GRIDDATA(...,'method') where 'method' is one of
> 'linear' - Triangle-based linear interpolation (default).
> 'cubic' - Triangle-based cubic interpolation.
> 'nearest' - Nearest neighbor interpolation.
> 'v4' - MATLAB 4 griddata method.
> defines the type of surface fit to the data. The 'cubic' and 'v4'
> methods produce smooth surfaces while 'linear' and 'nearest' have
> discontinuities in the first and zero-th derivative respectively. All
> the methods except 'v4' are based on a Delaunay triangulation of the
> data.
>
> See also GRIDDATA3, GRIDDATAN, DELAUNAY, INTERP2, MESHGRID.
>
>
>
>

>>>>> "Matt" == Matt Newville <new...@ca...> writes:

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

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

This is a known bottleneck.  Text layout is non-trivial in matplotlib.
Put it this way: you don't get multiline text with arbitrary rotation,
font properties, horizontal, vertical, and multiline alignment for
free.  Take a look at matplotlib.text.Text._get_layout.

I do cache the layout information because I've seen this performance
hit on animated demos before.  But if your text properties are
changing, caching doesn't help.  The cache key is returned by
Text.get_prop_tup.

It is probably worthwhile to run your animation through the profiler
so we can get a better idea of where exactly the problems are.  I
think the matrix multiplication that _get_layout uses for rotations is
slow.  It would be possible to special case the most common case
(rotation angle = 0) for some speedups, but the code is already fairly
hairy so I've been resisting special casing it.

FYI, the wxagg backend uses string methods to transfer the agg image
to the canvas.  tk and gtk use extension code.  fltk uses a python
buffer object.  I investigated the latter for wxagg but couldn't make
it work.  You may want to look into FigureCanvasWxAgg.draw to see if
you can do this image transfer faster, possibly adding some extension
code.  If you do go the extension code route, I suggest you try/except
the import on your extension code and fall back on the string method
already in place.

Oh, I added "newville" to the list of CVS developers.  Everyone,
welcome Matt, the new wx maintainer!

JDH

John Hunter Wrote:
> >>>>> "Chris" == Chris Barker <Chr...@no...> writes:
> 
>     Chris> 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.
> 
>     Chris> completely irregular? or only orthogonal structured
>     Chris> grids. From your description, it sounds like the
>     Chris> later. Could it take an unstructured set of (x,y,z) points
>     Chris> and contour the z values?
> 
> The latter, I believe.  The contouring routine was implemented by
> Nadia Dencheva (CCd on this mail) and is based on a gist routine.  You

Yes, the latter. For an unstructured set some other approach would be
needed. Sorry if I misunderstood. I thought what was being discussed
was irregular spacings rather than irregular organization.

Perry

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

    Eric> Hi, 1. slow plot 2. cursor issue 3. key press event !
    Eric> ------- 1/ Here is the piece of code which is quite slow I
    Eric> think. Compared to pgplot this is a factor of more than
    Eric> 10. It does first draw a default plot (0,1 ?)  and then
    Eric> overplot on it for each subplot.

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

Plots of this size should be extremely fast - you should be able to
plot arrays 10 times this big with good performance.  From your
description "It does first draw a default plot ..and then overplot on
it for each subplot." it sounds like you may have interactive mode
turned on.  This would kill your performance in a case like this,
because the entire figure would be redrawn with the update of every
single plotting command.  See
http://matplotlib.sourceforge.net/interactive.html and
http://matplotlib.sourceforge.net/faq.html#SHOW .

To definitively determine what mode you are in, run your script with 

 > python simple_plot.py --verbose-helpful

and verify that 'interactive is False'.  Fernando Perez's ipython has
support for running scripts from the interactive shell, turning off
interactive mode for the duration of the run, and then restoring it.

If this doesn't solve your problem please

  - post your entire script

  - report the output of verbose-helpful (requires matplotlib 0.64)

  - what is your platform, machine specs, etc?

  - how are you running the script (IDE, from the command prompt, etc)

JDH

>>>>> "Peter" == Peter Groszkowski <pgr...@ge...> writes:

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

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

This sounds pretty close to matlab's griddata function.  It would be
very nice to have this in matplotlib.mlab, perhaps as a wrapper to
some core scipy functionality, which could be conditionally imported.
What requirements does your code have -- pure python, extension code,
scipy, numarray?

Here is the matlab docstring, FYI

 GRIDDATA Data gridding and surface fitting.
    ZI = GRIDDATA(X,Y,Z,XI,YI) fits a surface of the form Z = F(X,Y)
    to the data in the (usually) nonuniformly-spaced vectors (X,Y,Z)
    GRIDDATA interpolates this surface at the points specified by
    (XI,YI) to produce ZI.  The surface always goes through the data
    points.  XI and YI are usually a uniform grid (as produced by
    MESHGRID) and is where GRIDDATA gets its name.
  
    XI can be a row vector, in which case it specifies a matrix with
    constant columns. Similarly, YI can be a column vector and it
    specifies a matrix with constant rows.
  
    [XI,YI,ZI] = GRIDDATA(X,Y,Z,XI,YI) also returns the XI and YI
    formed this way (the results of [XI,YI] = MESHGRID(XI,YI)).
  
    [...] = GRIDDATA(...,'method') where 'method' is one of
        'linear'    - Triangle-based linear interpolation (default).
        'cubic'     - Triangle-based cubic interpolation.
        'nearest'   - Nearest neighbor interpolation.
        'v4'        - MATLAB 4 griddata method.
    defines the type of surface fit to the data. The 'cubic' and 'v4'
    methods produce smooth surfaces while 'linear' and 'nearest' have
    discontinuities in the first and zero-th derivative respectively.  All
    the methods except 'v4' are based on a Delaunay triangulation of the
    data.
  
    See also GRIDDATA3, GRIDDATAN, DELAUNAY, INTERP2, MESHGRID.

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:

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

    Chris> completely irregular? or only orthogonal structured
    Chris> grids. From your description, it sounds like the
    Chris> later. Could it take an unstructured set of (x,y,z) points
    Chris> and contour the z values?

The latter, I believe.  The contouring routine was implemented by
Nadia Dencheva (CCd on this mail) and is based on a gist routine.  You
can read more about the core routine at
http://scipy.net/cgi-bin/viewcvsx.cgi/*checkout*/scipy1/xplt/src/gist/gcntr.c?rev=HEAD&content-type=text/plain.

The contour routines have been checked into CVS.  A simple example can
be found in examples/contour_demo.py in CVS.  We have some rudimentary
support for labeling (auto-legend and/or brute-force use of the text
command).  It would be nice to develop a point and click labeling
widget and/or an auto-labeling routine.  Contributors of course always
welcome!

JDH

>>>>> "Humufr" == Humufr  <hu...@ya...> writes:

    Humufr>        Hello, I have a problem to plot some data.

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

I just added the long awaited zorder attribute to the Artist base
class in CVS, originally discussed here
http://sourceforge.net/mailarchive/message.php?msg_id=9363527.

There is a new example examples/zorder_demo.py that shows you how to
set the zorder.  I'll include it below.

It will be in the next release, probably early next week

    #!/usr/bin/env python
    """
    The default drawing order for axes is patches, lines, text.  This
    order is determined by the zorder attribute.  The following default
    are set

    Artist                      Z-order
    Patch / PatchCollection      1
    Line2D / LineCollection      2
    Text                         3

    You can change the order for individual artists by setting the zorder.

    In the fist subplot below, the lines are drawn above the patch
    collection from the scatter, which is the default.

    In the subplot below, the order is reversed
    """

    from pylab import *
    x = rand(20); y = rand(20)

    subplot(211)
    plot(x, y, 'r', lw=3)
    scatter(x,y,s=120)

    subplot(212)
    plot(x, y, 'r', zorder=1, lw=3)
    scatter(x,y,s=120, zorder=2)

    show()

>>>>> "Arnold" == Arnold Moene <arn...@wu...> writes:

    Arnold> Dear all, At the moment I'm heavily using the scatter plot
    Arnold> (great!). But if I want to add a color bar (with the
    Arnold> command colorbar(), directly following the call to
    Arnold> scatter) to explain the meaning of the colors of the
    Arnold> patches, matplotlib (0.64) refuses to make a colorbar with
    Arnold> the following message:

I Arnold, thanks for alerting me to this problem.  This was a bug, and
is now fixed in CVS.  I should be releasing a new version of
matplotlib next week which has these changes plus more.

JDH

I have a few scripts that call show() multiple times.
(Why?  Well I had pedagogical reasons: I like one
graph to come up at a time in class, in the order
I wish, with no other "distractions".)

These scripts work as I wish if run with execfile() from the
(default Python) interpreter prompt.  (I.e., the first
figure is displayed, and when I close it the next is
displayed, etc.) If executed from the cmd line however they
fail:
    Fatal Python error: PyEval_RestoreThread: NULL tstate
    abnormal program termination
Can I add something to the scripts so that they behave
as I wish if executed from a cmd line?  (Am I wrong to
believe this used to work until recently; say last
version number or so?)

Aside from my wishes, should the script fail in this
fashion (rather than being more gracefully rejected)?
I realize we have been warned against using show()
multiple times ...

Somewhat related:
can I control the order in which figures are displayed
when the show() command is given, or will the highest
numbered figure always display on top?

Thank you,
Alan Isaac
Win 2000, Python 2.3.3, MatPlotLib 0.63

>>>>> "Delbert" == Delbert D Franz <iq...@so...> writes:

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

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

True!  But all of these demos do run for me.  I suggest you flush your
existing matplotlib by removing site-packages/matplotlib and your
"build" directory and reinstall from the official source at
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=281218.
Please follow the instructions at
http://matplotlib.sourceforge.net/installing.html, eg make sure you
have numeric or numarray installed when you compile matplotlib.

Let us know if you have more troubles, and please include a full
traceback from one of the date demos and run it with

> python date_demo1.py --verbose-helpful

and report the output.


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

It's a distutils thing.  Suggestions here welcome.

JDH

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:

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

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


This is basically what collections already do --
http://matplotlib.sourceforge.net/matplotlib.collections.html.
Typically when we find an area of code where a bunch of primitives are
being drawn independently, we refactor them as a collection.  There is
a default draw implementation in python that the backends can override
in extension code (as agg does).  Even if you just use the default
python drawing implementation, eg
backend_bases.RendererBase.draw_line_collection, the result is much
faster that instantiating a large number of independent objects.

Every property in a collection is a sequence (might be just length
one) and the drawing code iterates over the collection and gets the
value of a property for the i-th element of the collection as

  thisprop = prop[i % len(props)]

So if you have a len(1) list, every element in the collection shares
the prop, if you have a len(props) list, every element has a unique
property and < len(props) the props cycle.

Actually, a dictionary mapping element index to property value, which
has a default value, would be more flexible, and the performance hit
might not be bad.  Might be worth refactoring.

Actually, the code to plot line markers could be sped up by using
collections to draw line markers.  Currently we're using plain old
python loops for this.  

JDH

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.

completely irregular? or only orthogonal structured grids. From your 
description, it sounds like the later. Could it take an unstructured set 
of (x,y,z) points and contour the z values?

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