Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project!

## Re: [Matplotlib-users] scipy.xplt to matplotlib

 Re: [Matplotlib-users] scipy.xplt to matplotlib From: John Hunter - 2005-05-30 17:48:38 ```>>>>> "Fernando" == Fernando Perez writes: Fernando> One word of caution: you'll notice that in the above, Fernando> the xplt script runs very fast, while the mpl one is Fernando> unacceptably slow (and it consumes a TON of cpu). There Fernando> may be a trick to provide acceptable update speeds for Fernando> dynamically resized plots, but unfortunately I don't use Fernando> that kind of plotting much, so I can't really offer much Fernando> help there. Yes, this will run extremely slow, because each plot command creates a new matplotlib.lines.Line2D object, which at draw time means a new transformation, a new graphics context, etc. By the time you reach the end of the loop, you'll have a ton of extra overhead in object creation and function calls. If possible, I suggest creating just two line objects and manipulating their data directly, as in from math import sin, cos import matplotlib.numerix as nx import pylab pylab.ion() # interactive on, so each plot updates the window pylab.hold('on') allt = [0] # grow these lists and set the line data with them allsin = [sin(0)] allcos = [cos(0)] lsin, = pylab.plot(allt, allsin, 'g+') # lsin is a Line2D instance lcos, = pylab.plot(allt, allcos, 'ro') # lcos is a Line2D instance pylab.xlabel('Time t[s]') pylab.ylabel('Response') pylab.axis([0,10,-1,1]) for t in nx.arange(0.1,10,0.1): allt.append(t) allsin.append(sin(t)) allcos.append(cos(t)) lsin.set_data(allt, allsin) lcos.set_data(allt, allcos) pylab.draw() # to prevent the window from closing raw_input() Fernando> I get the feeling that there's an O(N^2) problem Fernando> somewhere in there, because it seems to me that the plot Fernando> update slows down worse than linearly as more points are Fernando> added. But I didn't really measure it, it's just a gut Fernando> feeling. This will still be slower than xplt, but shouldn't be mind-numbingly slow. I have some concrete ideas on how to make animation faster, and have started working on them, but don't have anything ready yet. JDH ```

 [Matplotlib-users] scipy.xplt to matplotlib From: Nils Wagner - 2005-05-30 15:27:20 ```Hi all, I am going to switch over to matplotlib. How can I convert the example with respect to matplotlib ? from scipy import * from scipy.xplt import * import gui_thread xplt.hold('on') for t in arange(0,10,0.1): xplt.plot(t,sin(t),'g+') xplt.pause(10) xplt.plot(t,cos(t),'ro') xplt.xlabel('Time t[s]') xplt.ylabel('Response') Nils ```
 Re: [Matplotlib-users] scipy.xplt to matplotlib From: Tim Leslie - 2005-05-30 15:59:17 ```On Mon, 30 May 2005, Nils Wagner wrote... > Hi all, >=20 > I am going to switch over to matplotlib. > How can I convert the example with respect to matplotlib ? >=20 >=20 > from scipy import * > from scipy.xplt import * > import gui_thread > xplt.hold('on') > for t in arange(0,10,0.1): > xplt.plot(t,sin(t),'g+') > xplt.pause(10) > xplt.plot(t,cos(t),'ro') > xplt.xlabel('Time t[s]') > xplt.ylabel('Response') import time =66rom pylab import * ion() for t in arange(0, 2, 0.1): scatter([t], [sin(t)], color=3D'g', marker=3D's') time.sleep(0.05) scatter([t], [cos(t)], color=3D'r', marker=3D'o') draw() xlabel('Time t[s]') ylabel('Response') ioff() show() This is how I would best approximate what your xplt code does. I'm sure someone will point out how this could be done better, but psuedo animation isn't my thing :) If you have a look around in the examples directory of the source distribution you should be able to find plenty of snippets which give you a feel for how to write matplotlib code. anim.py is kind of similar to what you've done here. Feel free to ask here if you have any other questions. Cheers, Tim >=20 > Nils >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22= 005 > _______________________________________________ > Matplotlib-users mailing list > Matplotlib-users@... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >=20 `- ```
 Re: [Matplotlib-users] scipy.xplt to matplotlib From: Fernando Perez - 2005-05-30 17:00:34 ```Nils Wagner wrote: > Hi all, > > I am going to switch over to matplotlib. > How can I convert the example with respect to matplotlib ? [~/test]> cat xplot.py #!/usr/bin/env python """xplt-based dynamic plot""" from scipy import * xplt.hold('on') for t in arange(0,10,0.1): xplt.plot(t,sin(t),'g+') xplt.pause(10) xplt.plot(t,cos(t),'ro') xplt.xlabel('Time t[s]') xplt.ylabel('Response') # to prevent the window from closing raw_input() [~/test]> cat pplot.py #!/usr/bin/env python """pylab-based dynamic plot""" from scipy import * import pylab pylab.ion() # interactive on, so each plot updates the window pylab.hold('on') for t in arange(0,10,0.1): pylab.plot([t],[sin(t)],'g+') pylab.plot([t],[cos(t)],'ro') pylab.xlabel('Time t[s]') pylab.ylabel('Response') # to prevent the window from closing raw_input() ### As you can see, all I did was pretty much do xplt->pylab, plus a few very minor changes. The matplotlib website has a lot of documentation, including illustrated screenshots, an examples package, a tutorial and a full user's guide. Since both mpl and xplt were trying to mimic matlab syntax, the transition should be pretty easy for you. One word of caution: you'll notice that in the above, the xplt script runs very fast, while the mpl one is unacceptably slow (and it consumes a TON of cpu). There may be a trick to provide acceptable update speeds for dynamically resized plots, but unfortunately I don't use that kind of plotting much, so I can't really offer much help there. I get the feeling that there's an O(N^2) problem somewhere in there, because it seems to me that the plot update slows down worse than linearly as more points are added. But I didn't really measure it, it's just a gut feeling. Cheers, f ```
 Re: [Matplotlib-users] scipy.xplt to matplotlib From: John Hunter - 2005-05-30 17:48:38 ```>>>>> "Fernando" == Fernando Perez writes: Fernando> One word of caution: you'll notice that in the above, Fernando> the xplt script runs very fast, while the mpl one is Fernando> unacceptably slow (and it consumes a TON of cpu). There Fernando> may be a trick to provide acceptable update speeds for Fernando> dynamically resized plots, but unfortunately I don't use Fernando> that kind of plotting much, so I can't really offer much Fernando> help there. Yes, this will run extremely slow, because each plot command creates a new matplotlib.lines.Line2D object, which at draw time means a new transformation, a new graphics context, etc. By the time you reach the end of the loop, you'll have a ton of extra overhead in object creation and function calls. If possible, I suggest creating just two line objects and manipulating their data directly, as in from math import sin, cos import matplotlib.numerix as nx import pylab pylab.ion() # interactive on, so each plot updates the window pylab.hold('on') allt = [0] # grow these lists and set the line data with them allsin = [sin(0)] allcos = [cos(0)] lsin, = pylab.plot(allt, allsin, 'g+') # lsin is a Line2D instance lcos, = pylab.plot(allt, allcos, 'ro') # lcos is a Line2D instance pylab.xlabel('Time t[s]') pylab.ylabel('Response') pylab.axis([0,10,-1,1]) for t in nx.arange(0.1,10,0.1): allt.append(t) allsin.append(sin(t)) allcos.append(cos(t)) lsin.set_data(allt, allsin) lcos.set_data(allt, allcos) pylab.draw() # to prevent the window from closing raw_input() Fernando> I get the feeling that there's an O(N^2) problem Fernando> somewhere in there, because it seems to me that the plot Fernando> update slows down worse than linearly as more points are Fernando> added. But I didn't really measure it, it's just a gut Fernando> feeling. This will still be slower than xplt, but shouldn't be mind-numbingly slow. I have some concrete ideas on how to make animation faster, and have started working on them, but don't have anything ready yet. JDH ```
 Re: [Matplotlib-users] scipy.xplt to matplotlib From: Arnd Baecker - 2005-05-30 21:15:57 ```On Mon, 30 May 2005, John Hunter wrote: > >>>>> "Fernando" == Fernando Perez writes: There is another point: For me the y-axis label does not show up in Fernando's example. Changing the end of the code to: ############################## raw_input("before x-label") pylab.xlabel('Time t[s]') raw_input("after x-label, before y-label") pylab.ylabel('Response') raw_input("after y-label") ##################### shows that the xlabel is shown after the pylab.ylabel line and the ylabel is never shown. This is on debian linux, python 2.3, matplotlib.__version__ 0.80 > Fernando> One word of caution: you'll notice that in the above, > Fernando> the xplt script runs very fast, while the mpl one is > Fernando> unacceptably slow (and it consumes a TON of cpu). There > Fernando> may be a trick to provide acceptable update speeds for > Fernando> dynamically resized plots, but unfortunately I don't use > Fernando> that kind of plotting much, so I can't really offer much > Fernando> help there. > > Yes, this will run extremely slow, because each plot command creates a > new matplotlib.lines.Line2D object, which at draw time means a new > transformation, a new graphics context, etc. By the time you reach > the end of the loop, you'll have a ton of extra overhead in object > creation and function calls. > > If possible, I suggest creating just two line objects and manipulating > their data directly, as in > > from math import sin, cos > import matplotlib.numerix as nx > import pylab > pylab.ion() # interactive on, so each plot updates the window > > pylab.hold('on') > allt = [0] # grow these lists and set the line data with them > allsin = [sin(0)] > allcos = [cos(0)] > lsin, = pylab.plot(allt, allsin, 'g+') # lsin is a Line2D instance > lcos, = pylab.plot(allt, allcos, 'ro') # lcos is a Line2D instance > pylab.xlabel('Time t[s]') > pylab.ylabel('Response') > pylab.axis([0,10,-1,1]) > for t in nx.arange(0.1,10,0.1): > allt.append(t) > allsin.append(sin(t)) > allcos.append(cos(t)) > lsin.set_data(allt, allsin) > lcos.set_data(allt, allcos) > pylab.draw() > > # to prevent the window from closing > raw_input() > > Fernando> I get the feeling that there's an O(N^2) problem > Fernando> somewhere in there, because it seems to me that the plot > Fernando> update slows down worse than linearly as more points are > Fernando> added. But I didn't really measure it, it's just a gut > Fernando> feeling. > > This will still be slower than xplt, but shouldn't be mind-numbingly > slow. On my machine it is slower by a factor 15 (import matplotlib ; matplotlib.rc.func_globals["get_backend"]() gives 'GTKAgg'). As I am a speed fanatic ;-) I would surely like this to be faster. But one should not forget that matplotlib does quite a lot (in particular antialising, sophisticated markers etc.). > I have some concrete ideas on how to make animation faster, and > have started working on them, but don't have anything ready yet. That sounds great - looking very much forward to this! Would this also result in a shorter code for the matplotlib example (which is at the moment more than twice as long than the scipy.xplt one)? Best, Arnd ```
 Re: [Matplotlib-users] scipy.xplt to matplotlib From: Fernando Perez - 2005-05-31 01:50:20 ```Arnd Baecker wrote: > On Mon, 30 May 2005, John Hunter wrote: > > >>>>>>>"Fernando" == Fernando Perez writes: > > > There is another point: > For me the y-axis label does not show up in Fernando's example. > > Changing the end of the code to: > ############################## > raw_input("before x-label") > pylab.xlabel('Time t[s]') > raw_input("after x-label, before y-label") > pylab.ylabel('Response') > raw_input("after y-label") > ##################### > shows that the xlabel is shown after the pylab.ylabel line > and the ylabel is never shown. Mmh, very strange. I can confirm that the labels do both (x/y) display correctly for me, on a Fedora Core 3 box using mpl 0.80 on Python 2.3.4 (the default), and the TkAgg backend. However, on my box all other backends (WX, GTK, Qt) fail to even open the display window _at all_. The code runs (confirmed by some print statements), but it never opens a window at all. This, despite the fact that these backends all work just fine in 'ipython -pylab'. Trying to get some info from matplotlib wasn't very enlightening: [~/test]> ./pplot.py --verbose-helpful matplotlib data path /usr/share/matplotlib loaded rc file /usr/local/home/fperez/.matplotlibrc matplotlib version 0.80 verbose.level helpful interactive is False platform is linux2 numerix Numeric 23.7 font search path ['/usr/share/matplotlib'] loaded ttfcache file /usr/local/home/fperez/.ttffont.cache backend GTKAgg version 2.4.1 t 0.0 t 0.1 t 0.2 t 0.3 [...] I haven't the foggiest idea what the problem may be... Best, f ```
 Re[2]: [Matplotlib-users] scipy.xplt to matplotlib From: Alan G Isaac - 2005-05-30 20:29:56 ```On Mon, 30 May 2005, John Hunter apparently wrote: > If possible, I suggest creating just two line objects and > manipulating their data directly, as in > from math import sin, cos > import matplotlib.numerix as nx > import pylab > pylab.ion() # interactive on, so each plot updates the window > pylab.hold('on') > allt = [0] # grow these lists and set the line data with them > allsin = [sin(0)] > allcos = [cos(0)] > lsin, = pylab.plot(allt, allsin, 'g+') # lsin is a Line2D instance > lcos, = pylab.plot(allt, allcos, 'ro') # lcos is a Line2D instance > pylab.xlabel('Time t[s]') > pylab.ylabel('Response') > pylab.axis([0,10,-1,1]) > for t in nx.arange(0.1,10,0.1): > allt.append(t) > allsin.append(sin(t)) > allcos.append(cos(t)) > lsin.set_data(allt, allsin) > lcos.set_data(allt, allcos) > pylab.draw() > # to prevent the window from closing > raw_input() 1. This is indeed much faster. 2. It still slows to a crawl as t grows. Should it? 3. The only thing that slows down is draw(), so the problem does not lie with the updating of the line instances. Alan Isaac P.S. Suppose I run the script and then press enter in the shell before closing the graph window. I get the following 'NULL tstate' error: Fatal Python error: PyEval_RestoreThread: Null tstate abnormal program termination Perhaps this is to be expected. ```
 Re: [Matplotlib-users] scipy.xplt to matplotlib From: John Hunter - 2005-05-31 14:18:31 ```>>>>> "Alan" == Alan G Isaac writes: Alan> 1. This is indeed much faster. 2. It still slows to a crawl Alan> as t grows. Should it? 3. The only thing that slows down is Alan> draw(), so the problem does not lie with the updating of the Alan> line instances. No, it shouldn't get significantly slower (it doesn't on my system) but I think I know what is wrong; in matplotlib-0.72 I introduced an optimization to make line marker drawing much faster - http://matplotlib.sourceforge.net/whats_new.html#0.72-line_marker_optimizations_in_agg - but quickly had to revert it for win32 because it caused a segfault in rare conditions, only on win32. I spent some time with Maxim, the antigrain author, but was never able to reproduce the segfault in standalone agg code. Last Friday I spent some time tracking it down and with the updated information, Maxim was able to find and fix the agg bug [Editor's note: I'm *very* proud to have found a bug in agg code -- they are very rare critters]. So the good news is the next mpl release will have the optimization also for win32. If you would like to give it a test drive, there is an alpha build at http://matplotlib.sf.net/matplotlib-0.81alpha.win32-py2.4.exe There have been fairly significant changes at the extension code level, so I suggest flushing your site-packages/matplotlib directory. Alan> P.S. Suppose I run the script and then press enter in the Alan> shell before closing the graph window. I get the following Alan> 'NULL tstate' error: Fatal Python error: Alan> PyEval_RestoreThread: Null tstate abnormal program Alan> termination Perhaps this is to be expected. We've never been able to free ourselves of this annoyance in all the contexts tkagg is used in (interactive, scripted, embedded, animation). If you search the archives, you'll see numerous threads on this one but as far as I can tell, it only happens at program termination in interactive/animated mode and is annoying but harmless. JDH ```