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
On 2005年5月30日, Nils Wagner <nw...@me...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>=20
`-
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
>>>>> "Fernando" == Fernando Perez <Fer...@co...> 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
On 2005年5月30日, John Hunter wrote:
> >>>>> "Fernando" == Fernando Perez <Fer...@co...> 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
Arnd Baecker wrote:
> On 2005年5月30日, John Hunter wrote:
>
>
>>>>>>>"Fernando" == Fernando Perez <Fer...@co...> 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
On 2005年5月30日, 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.
>>>>> "Alan" == Alan G Isaac <ai...@am...> 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