matplotlib-users Mailing List for matplotlib

Christian,
Hmm, it does sound like there might be a sizer conflict. Do you
get the tiny-figurecanvase behavior with the embedding_in_wx*.py
examples?? These have toolbars, but start off with reasonable
sizes, and respond to resizing ok for me.
--Matt

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

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.

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

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

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

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日, Mark Saward <ms...@bi...> wrote...
> Hi,
> 
> I need to make a small application that will do real time graphs. 
> Basically, it will receive data, and then:
> * store that data in a database
> * display it on a graph
> The graph will be Time vs Input so that a user can watch the graph 
> grow. Updates may be needed as quickly as 5 times per second.
> 
> Can matplotlib do this, or should I be looking at using something else? 
> If it can, how? I've taken a browse through the website but can't find 
> relevant information.
Have a look at anim.py in the examples directory of source distribution.
This should give you an idea of how to attack the problem. Feel free to
get back to us if you have any problems.
Cheers,
Tim
> 
> Mark
> 
> 
> -------------------------------------------------------
> 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=offad-ysdn-ostg-q22005
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
`-

Hi,
I need to make a small application that will do real time graphs. 
Basically, it will receive data, and then:
* store that data in a database
* display it on a graph
The graph will be Time vs Input so that a user can watch the graph 
grow. Updates may be needed as quickly as 5 times per second.
Can matplotlib do this, or should I be looking at using something else? 
If it can, how? I've taken a browse through the website but can't find 
relevant information.
Mark

Thanks, Matt!
It took me a while to understand this: Your mini-script worked like 
expected. I could change the size easily. But my own program still 
didn't react to any change in the figsize parameter.
However, as soon as I took out the toolbar, everything was fine! There 
seems to be a conflict with the sizers, which I could not solve until 
now. I will dive into this and post an update, if I find a solution.
Cheers
Christian
On 29 May 2005, at 05:08, Matt Newville wrote:
> Christian,
>
> I don't recall seeing this behavior of absurdly small figures
> and no response to figsize argement, even using wxPython 2.5.3
> on Mac OS X (though, admittedly I'm using matplotlib 0.8).
>
> The script below works fine for me, and changing the figsize
> argument to Figure() does change the figure size. Does this work
> for you -- you might have to change the wxversion.select() line,
> or just comment it out. If this works for you, can you post a
> simple, self-contained script that fails?
>
> Cheers,
>
> --Matt
>