From: Eric Emsellem <emsellem@ob...>  20041208 08:20:36

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 emsellem@... 9 av. CharlesAndre tel: +33 4 78 86 83 84 69561 SaintGenis Laval Cedex fax: +33 4 78 86 83 86 France http://wwwobs.univlyon1.fr/eric.emsellem =============================================================== 
From: Arnd Baecker <arnd.baecker@we...>  20041208 08:49:32

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.utokyo.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.tudresden.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). 
From: Perry Greenfield <perry@st...>  20041208 15:34:54

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 
From: LUK ShunTim <shuntim.luk@po...>  20041209 04:13:18

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  
From: Chris Barker <Chris.B<arker@no...>  20041209 19:16:16

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://www2.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) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@... 
From: Perry Greenfield <perry@st...>  20041209 19:32:47

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://www2.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 2d 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 
From: Perry Greenfield <perry@st...>  20041209 19:50:16

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 2d 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). 
From: Chris Barker <Chris.B<arker@no...>  20041209 21:17:14

Perry Greenfield wrote: >> Actually, I believe that the low level contour engine we are using >> supports this. It takes 2d 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) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@... 
From: John Hunter <jdhunter@ac...>  20041210 20:45:21

>>>>> "Chris" == Chris Barker <Chris.Barker@...> writes: Chris> Perry Greenfield wrote: >>> Actually, I believe that the low level contour engine we are >>> using supports this. It takes 2d 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/cgibin/viewcvsx.cgi/*checkout*/scipy1/xplt/src/gist/gcntr.c?rev=HEAD&contenttype=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 (autolegend and/or bruteforce use of the text command). It would be nice to develop a point and click labeling widget and/or an autolabeling routine. Contributors of course always welcome! JDH 
From: Perry Greenfield <perry@st...>  20041210 21:24:59

John Hunter Wrote: > >>>>> "Chris" == Chris Barker <Chris.Barker@...> writes: > > Chris> Perry Greenfield wrote: > > >>> Actually, I believe that the low level contour engine we are > >>> using supports this. It takes 2d 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 
From: Chris Barker <Chris.B<arker@no...>  20041211 00:46:19

John Hunter wrote: >>>>>>"Chris" == Chris Barker <Chris.Barker@...> 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) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@... 
From: Peter Groszkowski <pgroszko@ge...>  20041209 20:05:40
Attachments:
axPnuLC20041209_093841.70038018.png

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://www2.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 2d 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. 
From: Chris Barker <Chris.B<arker@no...>  20041209 21:15:17

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) 5266959 voice 7600 Sand Point Way NE (206) 5266329 fax Seattle, WA 98115 (206) 5266317 main reception Chris.Barker@... 
From: John Hunter <jdhunter@ac...>  20041210 20:52:40

>>>>> "Peter" == Peter Groszkowski <pgroszko@...> 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) nonuniformlyspaced 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'  Trianglebased linear interpolation (default). 'cubic'  Trianglebased 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 zeroth derivative respectively. All the methods except 'v4' are based on a Delaunay triangulation of the data. See also GRIDDATA3, GRIDDATAN, DELAUNAY, INTERP2, MESHGRID. 
From: Peter Groszkowski <pgroszko@ge...>  20041210 21:32:35

John Hunter wrote: >>>>>> "Peter" == Peter Groszkowski <pgroszko@...> 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) nonuniformlyspaced 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'  Trianglebased linear interpolation (default). > 'cubic'  Trianglebased 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 zeroth derivative respectively. All > the methods except 'v4' are based on a Delaunay triangulation of the > data. > > See also GRIDDATA3, GRIDDATAN, DELAUNAY, INTERP2, MESHGRID. > > > > 
From: Norbert Nemec <N<orbert@ne...>  20041209 16:32:16

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 ... D93053 Regensburg Tel: 0941  2009638 ... Mobil: 0179  7475199 eMail: <Norbert@...> 
From: John Hunter <jdhunter@ac...>  20041209 16:41:00

>>>>> "Norbert" == Norbert Nemec <Norbert@...> 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 
From: Norbert Nemec <Norbert.N<emec.list@gm...>  20041209 18:38:42

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 ... D93053 Regensburg Tel: 0941  2009638 ... Mobil: 0179  7475199 eMail: <Norbert@...> 
From: Matt Newville <newville@ca...>  20041209 19:52:35

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 redo 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 reissuing 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 
From: John Hunter <jdhunter@ac...>  20041210 21:31:11

>>>>> "Matt" == Matt Newville <newville@...> 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 nontrivial 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 
From: John Hunter <jdhunter@ac...>  20041209 16:45:26

>>>>> "Eric" == Eric Emsellem <emsellem@...> 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 
From: Eric Emsellem <emsellem@ob...>  20041209 17:16:37

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 1020 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, 'bo', ms=4) else : plot(self.Vrad[indgal][:minind], self.Vcoef[indgal][i][:minind], 'bo', 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], 'bo', 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 emsellem@... 9 av. CharlesAndre tel: +33 4 78 86 83 84 69561 SaintGenis Laval Cedex fax: +33 4 78 86 83 86 France http://wwwobs.univlyon1.fr/eric.emsellem =============================================================== 
From: John Hunter <jdhunter@ac...>  20041210 21:03:56

>>>>> "Eric" == Eric Emsellem <emsellem@...> 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 1020 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 verbosehelpful 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 verbosehelpful (requires matplotlib 0.64)  what is your platform, machine specs, etc?  how are you running the script (IDE, from the command prompt, etc) JDH 
From: Perry Greenfield <perry@st...>  20041211 02:06:36

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 verbosehelpful > > 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*(n1)/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 
From: John Hunter <jdhunter@ac...>  20041211 06:01:04

>>>>> "Perry" == Perry Greenfield <perry@...> 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 