matplotlib-users Mailing List for matplotlib

Chris Spencer <chrisspen@...> writes:
> 
> I had already encountered zunzun.com while Googling the problem. I'm
> not sure what to make of it, although it seems to be an online
> curve-fitting service. Unfortunately, my usage requires the ability to
> run the process locally.
The fitting source code for http://zunzun.com is freely available under a
BSD-style license on Google's source code repository at
http://code.google.com/p/pythonequations/downloads/list and comes with many
examples - so you *can* run it locally.
 James Phillips
 zu...@zu...
 http://zunzun.com

Hi Everyone,
I'm puzzled by the following problem:
If I do plot updates by using a callback triggered by the multiprocessing 
module's apply_async then the updates do not take - only the final result is 
shown, as if in non-interactive mode.
What could be the cause for this? Are there known issues using the 
multiprocessing module and interactive mode in matplotlib.
Thanks!
-Kaushik
matplotlib.__version__ -> '0.99.1.1'
Example code is below:
import pylab
import time
from multiprocessing import Pool
pylab.ion()
x = pylab.arange(0,2*pylab.pi,0.01)
line, = pylab.plot(x,pylab.sin(x))
start_time = time.time()
def time_waster():
 time.sleep(1)
def plot(Dummy=None):
 t = time.time() - start_time
 print t
 line.set_ydata(pylab.sin(x+t/1.0))
 pylab.draw()
for i in range(200):
 plot()
pool = Pool()
for N in range(60):
 pool.apply_async(time_waster,(),{},plot)
pool.close()
pool.join()

On Sep 20, 2010, at 9:58 PM, Ryan May wrote:
> On Mon, Sep 20, 2010 at 8:14 PM, Brian Blais <bb...@br...> wrote:
>> sure, but that take more effort, and I don't really care about a slow down, because most of my time is spent in the busy loop. 
> It might be more effort, but what you're doing now plays havoc with
> GUI event loops. Now, granted, until EPD upgrades to Matplotlib 1.0.0
> this won't work for you (unless you're willing to install your own),
> but this is how IMHO is best to approach this problem:
> 
...
> def busy_loop():
> for i in range(1000):
> r = np.random.rand(100,100)
> return r
> 
> def update_plot():
> update_plot.count += 1
> r = busy_loop()
> plt.clf()
> plt.imshow(r, interpolation='nearest', cmap=plt.get_cmap('gray'))
> plt.draw()
> dot()
> # Automatically stops after 10
> return update_plot.count < 10
> update_plot.count = 0
> 
> fig = plt.figure()
> # Creates a new timer that fires every 250 ms
> timer = fig.canvas.new_timer(interval=250)
> timer.add_callback(update_plot)
> timer.start()
> plt.show()
> 
> This, to me, isn't any more complex than your original (the most
> complex part comes from getting it to stop after a fixed number of
> iterations).
actually, I think the workflow that I use doesn't lend itself well to this. usually what I do is write code in the local space, in a if __name__=="__main__" block, so that after things run I can easily inspect variables, test the results, rerun, etc... It's only after things work that I box it into a nice function that can be called with an event callback. this is one of the reasons I use python, so that I can easily interact with my data. 
why does the way I wrote things play havoc with GUI event loops? it shouldn't care, or at worst the GUI parts of the window (menus, buttons) should be unresponsive when the plots are drawn but the plots should at least be drawn!
> The benefit is that the timed updates integrate into the
> GUI event loop and don't fight it. The other benefit is that this
> works with any of the interactive backends and you don't end up
> debugging weird draw problems. Even when I've gotten your style of
> animation to work in the past, I've still had problems where resizing
> the figure, etc. don't work.
perhaps I can write things this way, and have the function inject into locals(), just to make it easier to debug the results, but that seems to me to be a bit of a hack. I'm not really interested in an animation, as much as easily visualizing my data every so often. 
when people come from using matlab, and then hit odd draw problems like this, it is disconcerting. 
			bb
-- 
Brian Blais
bb...@br...
http://web.bryant.edu/~bblais
http://bblais.blogspot.com/

On Tue, Sep 21, 2010 at 8:22 AM, A. S. Budden <ab...@gm...> wrote:
> All,
>
> Now that NumPy is available for python 3.1 and SciPy is well on its
> way (apparently), are there any plans for matplotlib to be ported?
There are definitely plans; in fact, there's a SVN branch for it.
There are no major impediments--the branch can already run a simple
example. Unfortunately, development time seems to be quite a lacking
resource of late (I *know* it has for me). Patches, however, are
always accepted. :)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Sep 21, 2010 at 9:02 AM, Bala subramanian <bal...@gm...
> wrote:
> Friends,
> I have a file like below. Where i have data in row 1 to 8, then a gap, then
> data for row 10-16. I want matplotlib to explicitly consider this gap and
> not to shift the y values while plotting. How can i achieve this ?. I tried
> by inserting a string 'None' instead of gap, but i get error.
>
> 20.6 -24.0
> 39.0 24.3
> 12.7 11.8
> 135.8 141.4
> 56.6 80.9
> -84.5 104.1
> -28.0 -28.6
> 1.1 16.7
>
> 9.9 19.1
> -9.8 1.5
> 17.4 17.0
> -2.0 16.6
> 10.3 4.4
> 7.2 10.9
>
>
>
Bala, instead of spaces, try 'NaN NaN' (without quotes).
I hope that works!
Ben Root

Friends,
I have a file like below. Where i have data in row 1 to 8, then a gap, then
data for row 10-16. I want matplotlib to explicitly consider this gap and
not to shift the y values while plotting. How can i achieve this ?. I tried
by inserting a string 'None' instead of gap, but i get error.
 20.6 -24.0
 39.0 24.3
 12.7 11.8
135.8 141.4
 56.6 80.9
-84.5 104.1
-28.0 -28.6
 1.1 16.7
 9.9 19.1
 -9.8 1.5
 17.4 17.0
 -2.0 16.6
 10.3 4.4
 7.2 10.9

All,
Now that NumPy is available for python 3.1 and SciPy is well on its
way (apparently), are there any plans for matplotlib to be ported?
Al

Hi,
Scipy.optimize.leastsq finds a least square fit to an arbitrary function. Check the scipy cookbook example: http://www.scipy.org/Cookbook/FittingData
Regards,
Bartosz
On 20.09.2010, at 22:36, Chris Spencer wrote:
> Hi,
> 
> Does Matplotlib/Numpy/Scipy contain the ability to fit a sigmoid curve
> to a set of data points?
> 
> Regards,
> Chris
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Bartosz Telenczuk
Institute for Theoretical Biology
Humboldt University of Berlin
Germany
http://neuroscience.telenczuk.pl

==========================
SciPy 2010 Call for Papers
==========================
The second `SciPy India Conference <http://scipy.in>`_ will be held
from December 13th to 18th, 2010 at `IIIT-Hyderabad
<http://www.iiit.ac.in/>`_.
At this conference, novel applications and breakthroughs made in the
pursuit of science using Python are presented. Attended by leading
figures from both academia and industry, it is an excellent
opportunity to experience the cutting edge of scientific software
development.
The conference is followed by two days of tutorials and a code sprint,
during which community experts provide training on several scientific
Python packages.
We invite you to take part by submitting a talk abstract on the
conference website at:
http://scipy.in
Talk/Paper Submission
==========================
We solicit talks and accompanying papers (either formal academic or
magazine-style articles) that discuss topics regarding scientific
computing using Python, including applications, teaching, development
and research. Papers are included in the peer-reviewed conference
proceedings, published online.
Please note that submissions primarily aimed at the promotion of a
commercial product or service will not be considered.
Important Dates
==========================
Monday, Oct. 11: Abstracts Due
Saturday, Oct. 30: Schedule announced
Tuesday, Nov. 30: Proceedings paper submission due
Monday-Tuesday, Dec. 13-14: Conference
Wednesday-Friday, Dec. 15-17: Tutorials/Sprints
Saturday, Dec. 18: Sprints
Organizers
==========================
* Jarrod Millman, Neuroscience Institute, UC Berkeley, USA (Conference Co-Chair)
* Prabhu Ramachandran, Department of Aerospace Engineering, IIT
Bombay, India (Conference Co-Chair)
* FOSSEE Team

bevan j wrote:
> 
> Sorry if it has already been reported I searched in the bug reports for
> qt4agg and didn't find anything. Although I may have been looking in the
> wrong place.
> I have also noticed that editing some parameters (or pressing apply
> without any changes) alters others. For instance if I have:
> from matplotlib import pyplot 
> import numpy as np 
> 
> a = np.random.rand(12) 
> 
> fig = pyplot.figure() 
> ax = fig.add_subplot(111)
> wdth = 0.20
> ind = np.arange(a.size) 
> mon_ticks =('Jan','Feb','Mar','Apr','May','Jun','Jul', 'Aug', 'Sep',
> 'Oct', 'Nov','Dec')
> ax.bar(ind, a, wdth, color='0.8')
> ax.set_xticks(ind)
> ax.set_xticklabels(mon_ticks)
> pyplot.show() 
> Then pressing apply removes the ticks and tick label setting.
> 
> Hopefully this is adressed in the bug report you mention. Thanks.
> 
@bevan j: nothing wrong with reporting bugs that should have been solved
long ago.
Patches that correct the issues you mentioned initially have indeed been
submitted, but have not be included in matplotlib as of yet. >> Look in
patches at the mpl tracker.
The last issue with the tick labels on the other hand is more difficult.
Please note that Tick labels are not supported by figure_options currently. 
If you haven't changed any settings that make your ticks go away, it would
be possible to ensure your plot is not messed up by qt4_editor when you
click apply/OK, but this feature has not been implemented yet.
-- 
View this message in context: http://old.nabble.com/Qt4Agg-backend---edit-curves-and-axis-parameters-tp29754925p29765678.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Thanks! This was helpful.
On Mon, Sep 20, 2010 at 5:43 PM, Benjamin Root <ben...@ou...> wrote:
> On Mon, Sep 20, 2010 at 5:01 PM, John Salvatier <jsalvati@u.washington.edu
> > wrote:
>
>> Hello,
>>
>> Is there a way to do "asynchronous" plots in matplotlib? By asynchronous I
>> mean plots that simply spawn a new process and do not stop the program while
>> the plot is visible? For example, I would like to be able to run a script
>> that plots something and have the program end with the plot still useable so
>> I can run the script again and generate a slightly different plot that I can
>> compare side by side with the first.
>>
>> John
>>
>>
> John,
>
> matplotlib does have an interactive mode that can be turned on with a call
> to plt.ion(). Note that any figure is spawned as a child thread. If you
> run a script from the command line, the script won't end until the figure is
> closed (hence you can't start another script).
>
> However, another possible route is to design your code as functions that
> take a figure or axes object, you could then just call the needed functions
> for an existing axes object.
>
> Another possibility (and maybe this is what you meant originally) is to
> have a python or ipython session open and import the desired scripts in
> order to execute them (with interactive mode turned on).
>
> I hope this is helpful!
> Ben Root
>
>

On Mon, Sep 20, 2010 at 8:14 PM, Brian Blais <bb...@br...> wrote:
> sure, but that take more effort, and I don't really care about a slow down, because most of my time is spent in the busy loop. I do
> care about it displaying *at all*, which is the problem. I am familiar with the efficient way of animating, but for most things I want to
> focus on the computation and then display here and there, so I want the shortest, clearest plotting code without any optimizations. if I
> call plot commands, and then a draw, I expect it to actually pause right there until it is done drawing, and then continue...it's not doing
> that.
It might be more effort, but what you're doing now plays havoc with
GUI event loops. Now, granted, until EPD upgrades to Matplotlib 1.0.0
this won't work for you (unless you're willing to install your own),
but this is how IMHO is best to approach this problem:
import matplotlib.pyplot as plt
import numpy as np
import sys
def dot():
 sys.stdout.write('.')
 sys.stdout.flush()
def busy_loop():
 for i in range(1000):
 r = np.random.rand(100,100)
 return r
def update_plot():
 update_plot.count += 1
 r = busy_loop()
 plt.clf()
 plt.imshow(r, interpolation='nearest', cmap=plt.get_cmap('gray'))
 plt.draw()
 dot()
 # Automatically stops after 10
 return update_plot.count < 10
update_plot.count = 0
fig = plt.figure()
# Creates a new timer that fires every 250 ms
timer = fig.canvas.new_timer(interval=250)
timer.add_callback(update_plot)
timer.start()
plt.show()
This, to me, isn't any more complex than your original (the most
complex part comes from getting it to stop after a fixed number of
iterations). The benefit is that the timed updates integrate into the
GUI event loop and don't fight it. The other benefit is that this
works with any of the interactive backends and you don't end up
debugging weird draw problems. Even when I've gotten your style of
animation to work in the past, I've still had problems where resizing
the figure, etc. don't work.
Hope this helps (at least in the future),
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Mon, Sep 20, 2010 at 8:14 PM, Brian Blais <bb...@br...> wrote:
> On Sep 20, 2010, at 7:43 PM, Benjamin Root wrote:
>
> > On Mon, Sep 20, 2010 at 5:12 PM, Brian Blais <bb...@br...> wrote:
>
> > I am trying to do some simple calculations in a loop, and draw a plot
> periodically within the loop, and the drawing is not updating. I'm using
> the Enthought Python Distribution which is using Matplotlib 0.99.3 with
> python 2.6.5 on Snow Leopard, OSX 10.6.4, and am running it in ipython with
> the -pylab flag (and I've tried with the -wthread flag too). A sample piece
> of code below. It is actually drawing, because when I control-C to stop, it
> shows the plot.
> >
> > from pylab import *
> > from numpy import *
> > import sys
> >
> > def dot():
> > sys.stdout.write('.')
> > sys.stdout.flush()
> >
> > def busy_loop():
> >
> > for i in range(1000):
> > r=rand(100,100)
> >
> > return r
> >
> > for t in range(1000):
> >
> > r=busy_loop()
> >
> > clf()
> > imshow(r,interpolation='nearest',cmap=cm.gray)
> > draw()
> > show()
> >
> > dot()
> >
> > First, I would suggest using time.sleep() to do your busy loop:
> >
> > >>> import time
> > >>> time.sleep(0.1)
> >
>
> I tried that before (even upping to 1 second)...no dice.
>
>
When you say 'no dice', do you mean that it didn't pause execution at all,
or that it didn't solve your problem? Note that I wasn't implying that it
would solve your problem, only that it was probably a cleaner way to write
code and it gives you explicit control over how long to wait regardless of
which computer you are on.
> >
> > Second, you have the show() function within the loop. Call the show()
> function only once (in interactive mode), and draw() can be used to update
> the graph.
>
> also done...no effect.
>
Well, in any case, you should only have a single show() call for this use
case. draw() is used by show() to actually perform the rendering. Whatever
issue you are having, it isn't from you calling show() only once.
>
> > Also note that some plotting functions return objects that have a
> function like "update_data" that would allow you to modify the plot without
> having to call clf().
>
> sure, but that take more effort, and I don't really care about a slow down,
> because most of my time is spent in the busy loop. I do care about it
> displaying *at all*, which is the problem. I am familiar with the efficient
> way of animating, but for most things I want to focus on the computation and
> then display here and there, so I want the shortest, clearest plotting code
> without any optimizations. if I call plot commands, and then a draw, I
> expect it to actually pause right there until it is done drawing, and then
> continue...it's not doing that.
>
>
>
And that's the way it is supposed to work.
> another wrinkle: If I run ipython -pylab, and then run my script like:
>
> run do_my_script
>
> I get no plot showing (an empty figure window shows, with a busy process
> "rainbow spiral). Now, I control-C and the plots come up and my script
> stops. I then type again:
>
> run do_my_script
>
> it works! once the figure is drawn once, it seems to work just fine. the
> *first* time it doesn't display, and requires a control-C. weird!
>
> can anyone reproduce this?
>
> bb
>
>
This might be an issue with the somewhat older version of matplotlib that is
with EPD. I know there have been some significant fixes with the
interactivity of plots. But I haven't seen this much of an issue.
Give this a shot... run ipython -pylab and create some figure by hand, call
.show(), and then do something else to the plot. No calls to draw() and
only one initial call to show() to get the figure window up, I am just
curious if the figure updates itself on its own.
Ben Root

Thank you. I'll try investigating Scipy further. I've already tried
applying some least-squares code for Numpy
(http://pingswept.org/2009/01/24/least-squares-polynomial-fitting-in-python/)
to my sigmoid data, but it only seems to fit parabolas.
I had already encountered zunzun.com while Googling the problem. I'm
not sure what to make of it, although it seems to be an online
curve-fitting service. Unfortunately, my usage requires the ability to
run the process locally.
Regards,
Chris
On Mon, Sep 20, 2010 at 6:35 PM, Gökhan Sever <gok...@gm...> wrote:
> On Mon, Sep 20, 2010 at 3:36 PM, Chris Spencer <chr...@gm...> wrote:
>>
>> Hi,
>>
>> Does Matplotlib/Numpy/Scipy contain the ability to fit a sigmoid curve
>> to a set of data points?
>
> You could also experiment at zunzun.com. Choose 2D sigmoidal from the 2D
> function scroll list.
> --
> Gökhan
>

On Sep 20, 2010, at 7:43 PM, Benjamin Root wrote:
> On Mon, Sep 20, 2010 at 5:12 PM, Brian Blais <bb...@br...> wrote:
> I am trying to do some simple calculations in a loop, and draw a plot periodically within the loop, and the drawing is not updating. I'm using the Enthought Python Distribution which is using Matplotlib 0.99.3 with python 2.6.5 on Snow Leopard, OSX 10.6.4, and am running it in ipython with the -pylab flag (and I've tried with the -wthread flag too). A sample piece of code below. It is actually drawing, because when I control-C to stop, it shows the plot.
> 
> from pylab import *
> from numpy import *
> import sys
> 
> def dot():
> sys.stdout.write('.')
> sys.stdout.flush()
> 
> def busy_loop():
> 
> for i in range(1000):
> r=rand(100,100)
> 
> return r
> 
> for t in range(1000):
> 
> r=busy_loop()
> 
> clf()
> imshow(r,interpolation='nearest',cmap=cm.gray)
> draw()
> show()
> 
> dot()
> 
> First, I would suggest using time.sleep() to do your busy loop:
> 
> >>> import time
> >>> time.sleep(0.1)
> 
I tried that before (even upping to 1 second)...no dice.
> 
> Second, you have the show() function within the loop. Call the show() function only once (in interactive mode), and draw() can be used to update the graph.
also done...no effect.
> Also note that some plotting functions return objects that have a function like "update_data" that would allow you to modify the plot without having to call clf().
sure, but that take more effort, and I don't really care about a slow down, because most of my time is spent in the busy loop. I do care about it displaying *at all*, which is the problem. I am familiar with the efficient way of animating, but for most things I want to focus on the computation and then display here and there, so I want the shortest, clearest plotting code without any optimizations. if I call plot commands, and then a draw, I expect it to actually pause right there until it is done drawing, and then continue...it's not doing that. 
another wrinkle: If I run ipython -pylab, and then run my script like:
run do_my_script
I get no plot showing (an empty figure window shows, with a busy process "rainbow spiral). Now, I control-C and the plots come up and my script stops. I then type again:
run do_my_script
it works! once the figure is drawn once, it seems to work just fine. the *first* time it doesn't display, and requires a control-C. weird!
can anyone reproduce this?
			bb
-- 
Brian Blais
bb...@br...
http://web.bryant.edu/~bblais
http://bblais.blogspot.com/

On Mon, Sep 20, 2010 at 5:01 PM, John Salvatier
<jsalvati@u.washington.edu>wrote:
> Hello,
>
> Is there a way to do "asynchronous" plots in matplotlib? By asynchronous I
> mean plots that simply spawn a new process and do not stop the program while
> the plot is visible? For example, I would like to be able to run a script
> that plots something and have the program end with the plot still useable so
> I can run the script again and generate a slightly different plot that I can
> compare side by side with the first.
>
> John
>
>
John,
matplotlib does have an interactive mode that can be turned on with a call
to plt.ion(). Note that any figure is spawned as a child thread. If you
run a script from the command line, the script won't end until the figure is
closed (hence you can't start another script).
However, another possible route is to design your code as functions that
take a figure or axes object, you could then just call the needed functions
for an existing axes object.
Another possibility (and maybe this is what you meant originally) is to have
a python or ipython session open and import the desired scripts in order to
execute them (with interactive mode turned on).
I hope this is helpful!
Ben Root

On Mon, Sep 20, 2010 at 6:44 PM, bevan j <be...@gm...> wrote:
>
>
> Benjamin Root-2 wrote:
> >
> > On Sun, Sep 19, 2010 at 5:23 PM, bevan j <be...@gm...> wrote:
> >
> >> selindex = value.pop(0)
> >> AttributeError: 'tuple' object has no attribute 'pop'
> >>
> >
> > Didn't we just have a bug report/fix for this one?
> >
> >
> Sorry if it has already been reported I searched in the bug reports for
> qt4agg and didn't find anything. Although I may have been looking in the
> wrong place.
> I have also noticed that editing some parameters (or pressing apply without
> any changes) alters others. For instance if I have:
> from matplotlib import pyplot
> import numpy as np
>
> a = np.random.rand(12)
>
> fig = pyplot.figure()
> ax = fig.add_subplot(111)
> wdth = 0.20
> ind = np.arange(a.size)
> mon_ticks =('Jan','Feb','Mar','Apr','May','Jun','Jul', 'Aug', 'Sep', 'Oct',
> 'Nov','Dec')
> ax.bar(ind, a, wdth, color='0.8')
> ax.set_xticks(ind)
> ax.set_xticklabels(mon_ticks)
> pyplot.show()
> Then pressing apply removes the ticks and tick label setting.
>
> Hopefully this is adressed in the bug report you mention. Thanks.
>
Bevan, don't worry, the question wasn't directed to you.
I found the email I was thinking of:
http://permalink.gmane.org/gmane.comp.python.matplotlib.devel/9212
Titled: [PATCH] Fix line color setting on Qt4
I don't know if this addresses the other issues the Bevan made, though...
Ben Root