matplotlib-users Mailing List for matplotlib

On Sun, Jan 29, 2012 at 2:29 PM, Jerzy Karczmarczuk
<jer...@un...> wrote:
> This is a temporal pause, not an undetermined suspension, restartable.

Ah, never mind then.  I didn't read the docstring and misunderstood
the discussion in the pull request.

Cheers,

f

Fernando Perez:
> I now see there's even a pause() call:
>
> https://github.com/matplotlib/matplotlib/pull/148
>
> so it seems like it should be an easy matter of adding the button and
> wire it to pause().
This is a temporal pause, not an undetermined suspension, restartable.

Jerzy

On Sun, Jan 29, 2012 at 12:20 PM, Jerzy Karczmarczuk
<jer...@un...> wrote:

> This happens also with different backends and the driving interface (say,
> Idle with Tkinter...)
> Some solutions exist. The simplest one is the following.

Thanks for the tips!  It would really be nice if in animation mode,
the mpl windows had automatically a play/pause toggle at the very
least, so that regular users could get more functional animations
without having to wire these extra tricks.

I now see there's even a pause() call:

https://github.com/matplotlib/matplotlib/pull/148

so it seems like it should be an easy matter of adding the button and
wire it to pause().   Perhaps one of your students could make a nice
contribution :)

> Absolutely.
> But first, you don't need to launch show() and force some mainloop(),
> MainLoop(), gtk.main(), etc. under the hood. We wrote some loops under wx,
> simple-minded ; there is one included in the standard docs-and-demos. I
> don't know yet how to force WindowUpdate from Matplotlib, but some "plugin"
> solution should exist, since Matplotlib does that already.
>
> Second, even if an event loop runs already, the question is to plug in the
> access to the concrete event queue mechanism, not to superpose another one,
> and yell with horror at which level declare callbacks...

Best of luck.  Having burned many hours on the ipython/matplotlib
event loop integration over the years, I don't envy you right now if
you're going to fight this little battle... But I'll happily cheer you
from the safety of the sidelines :)

Cheers,

f

Fernando Perez :
> The lack of a clean pause/restart
> functionality is indeed problematic.  Furthermore, closing a window
> that's running an animation, at least with the Qt backend, gave rise
> to a massive swarm of 'C++ object has been deleted' messages flooding
> the console where my ipython kernel had been started.
This happens also with different backends and the driving interface 
(say, Idle with Tkinter...)
Some solutions exist. The simplest one is the following.
1. Use a particular event source, e.g. launch:

    ani = anima.FuncAnimation(fig, proc, repeat=False, frames=sourcegen)


where

    def sourcegen():
         while running: yield 0 #or whatever
         return

Include a button

    def astop(ev=None):
         global running
         running=False
    stopbutton.on_clicked(astop)

and it will kill your animation in a proper way. Restarting it demands 
that "ani"  be recreated within a callback, say, a startbutton.
But this is not pausing. Recreating the animation, recreating and 
starting a timer, connecting all the callbacks... this takes time, and 
you SEE it.

> if you go down the road of implementing a
> full-blown event loop for matplotlib, is how well it will play with
> existing event loops. Whenever an interactive GUI backend is running,
> there's already an event loop at work: that of the GUI toolkit.
> Integrating multiple event loops in the same process takes some
> delicate footwork if you don't want to end up with a nasty fight
> between the two.
Absolutely.
But first, you don't need to launch show() and force some mainloop(), 
MainLoop(), gtk.main(), etc. under the hood. We wrote some loops under 
wx, simple-minded ; there is one included in the standard 
docs-and-demos. I don't know yet how to force WindowUpdate from 
Matplotlib, but some "plugin" solution should exist, since Matplotlib 
does that already.

Second, even if an event loop runs already, the question is to plug in 
the access to the concrete event queue mechanism, not to superpose 
another one, and yell with horror at which level declare callbacks...

Thank you, Fernando.

Jerzy Karczmarczuk

Hello all,

I'm new to using Matplotlib.  I am on Ubuntu 10.4, and I installed through apt-get.  I then downloaded and installed basemap according to the instructions on the basemap site.  However, when I run simpletest.py from the basemap package, I get an error "ImportError: No module named axes_grid1".  I thought this was a basemap problem at first, but I can reproduce this error using matplotlib tests.  Am I doing something wrong?  As I understand it, axes_grid1 is a set of helper classes which comes with Matplotlib.  Does it need to be installed?  Thanks!

-BG
 

On Sun, Jan 29, 2012 at 3:41 AM, Jerzy Karczmarczuk
<jer...@un...> wrote:
>
>
> There is one "rant", if you wish (of course, I am joking).
>
> The animation objects (FuncAnimation, etc.) are coded as they are,
> probably sufficient for you. They are "one shot". But if you want to
> stop and to resume your animation, they are not so well adapted.

Actually many thanks for this very interesting discussion!  Just on
Friday I came to this same conclusion while preparing some lecture
material using animations.  The lack of a clean pause/restart
functionality is indeed problematic.  Furthermore, closing a window
that's running an animation, at least with the Qt backend, gave rise
to a massive swarm of 'C++ object has been deleted' messages flooding
the console where my ipython kernel had been started.

One thing to keep in mind, if you go down the road of implementing a
full-blown event loop for matplotlib, is how well it will play with
existing event loops. Whenever an interactive GUI backend is running,
there's already an event loop at work: that of the GUI toolkit.
Integrating multiple event loops in the same process takes some
delicate footwork if you don't want to end up with a nasty fight
between the two.

In any case, keep us posted on any progress!

Best,

f

On Sunday, January 29, 2012, Jerzy Karczmarczuk <
jer...@un...> wrote:
> I believe that I should terminate this thread (from my side), since the
image is clear. The actual version of Matplotlib is not adapted to my
needs, a rather involved animation of many objects, and changing. The last
dialogue with Benjamin Root, whom I am deeply grateful, cleared my doubts.
Ben confirms that I am on my own:
>
>> // you need to create your web of callbacks accordingly.  The callback
registry is just simply a tool that we created for our use.  Keep in mind
that your original question to this thread was "how do I fire events?".  I
answered that question a while back.
>
> My question - sorry for being unclear - was how to fire events
ASYNCHRONOUSLY. How to post them, to be processed by the event loop, not
how to call callbacks.
>
>>  Ok, but the callback registry is not an event loop.  It is just a
callback registry.  The main-loops are in the respective GUI toolkits.
>
> I know that. I read a good part of the matlotlib source, but not all of
this, since I thought that asking questions might be more efficient.  And
actually it was.
>
>>  There is no event queue in the CallbackRegistry.  What we have done in
the respective GUI backends is to link various GUI actions to calls to
process().  The CallbackRegistry itself is GUI-neutral and heck, it doesn't
even assume a GUI exists, which allows for us to still use the callback
registry for other uses in non-interactive modes and headless modes.
 Therefore, there is no mainloop, there is no event queue.
>
> This, I believe, is the final answer. Sigh. OK. I am not saved from the
Pooh syndrome (The more he looked inside the more Piglet wasn't there),
since now I plan to either code something myself, or to give it as a
project to my students. I believe that Matplotlib merits this, there is
plenty of potentialities, but the animation seems to be still in statu
nascendi.
>
>>  I also noticed that in the example you posted, you created your own
callback registry.  Why didn't you use the existing one that comes with the
figure canvas?
>>
> Oh, of course. But this was accidental, it doesn't change anything.
>
>> Quite honestly, I (and I suspect others) are not sure what you are
asking of us.  You seem to be quite knowledgeable, but -- quite frankly --
all I see is you complaining about the problem.  /.../ I need you to be
very clear about what you want and to exclude any extraneous "rants" you
may have.
>
> NO SIR. I am not complaining (cite my "complaints" if you disagree). I am
trying to find a solution to a problem of delayed, asynchronous event
processing within Matplotlib. I try to be compact, this is just a mailing
list. And please: what "rants"??? I would never say anything bad about the
system nor its authors, I am asking questions. No bugs to reports (only
that from time to time Python declares some execution error of a
sub-process, but it may have several sources).
>
>> My only guess is that you were hoping that there was a GUI-neutral
mainloop in mpl.  I am sorry to say that one doesn't exist in the manner
you are speaking.
>
> Again, this IS the answer. Thank you very much.
>
> ================
>
> There is one "rant", if you wish (of course, I am joking).
>
> The animation objects (FuncAnimation, etc.) are coded as they are,
probably sufficient for you. They are "one shot". But if you want to stop
and to resume your animation, they are not so well adapted. Calling ._stop
(not documented) from a callback is deadly, because of the cleaning
procedures. You can't re-_start it. The only way - as I see it - is to
create another animation. OK, but this might not be the most efficient way
to do it.
>
> I am afraid that my fascination by Matplotlib, which I really use for my
teaching of scientific programming and visualization, pushed me to try to
use the package outside its actual limits. Sorry bor bothering you. If I
find something of general interest, I will post it, perhaps.
>
> All the best, sincerely.
>
> Jerzy Karczmarczuk
> Caen, France
>
>

No problem, I am glad to see the question cleared up. I suspect that what I
interpreated as a rant was more related to my frustrations, so I apologize.

I wonder if the Timer class in cbook.py might be useful to you? It is
GUI-neutral and it could act as a global "heartbeat" for your simulator.

As for your issues with the animation class.  It is a very new feature and
we welcome any feedback.  The _stop() function is intended, iirc, to be
used for when the figure window closes.  What you are looking for is some
sort of pause() function. Feel free to file a feature request on mpl's
github page.

Cheers!
Ben Root

On Sun, Jan 29, 2012 at 2:21 AM, Paul Hobson <pmh...@gm...> wrote:

> There is undoubtedly a more efficient way to do this, but give this a shot:
>
> import numpy as np
> import matplotlib.pyplot as plt
>
> x = np.arange(0, 10.5, 0.5)
> y = -3.0*x + 0.5*x**2
>
> color_list = ['FireBrick', 'Orange', 'DarkGreen', 'DarkBlue', 'Indigo']
> limits = np.arange(0, 11, 2)
> fig, ax1 = plt.subplots()
> for n, color in enumerate(color_list):
>    lower = np.where(x >= limits[n])[0]
>    upper = np.where(x <= limits[n+1])[0]
>    index = np.intersect1d(lower, upper)
>    ax1.plot(x[index], y[index], linestyle='-', color=color, linewidth=2)
>
> plt.show()
>
> HTH,
> -paul
>

Alternatively, you could replace the loop above with::

    indexes = np.searchsorted(x, limits)
    # add 1 to end index so that segments overlap
    for i0, i1, color in zip(indexes[:-1], indexes[1:]+1, color_list):
        ax1.plot(x[i0:i1], y[i0:i1], linestyle='-', color=color,
linewidth=2)

This is not much different than Paul's example---just whatever you find
more readable.

-Tony


>
> On Fri, Jan 27, 2012 at 8:12 AM, nahren manuel <mee...@ya...>
> wrote:
> > Dear Users,
> > I want to plot a XY, the X-value is constant, but let assume Y varees
> from
> > 1-10, so I want o have different colors accordingly for the range
> > 0-2,2-4,4-6,6-8,8-10.
> >
> > thanks a lot
> > najren
> >
> >
> ------------------------------------------------------------------------------
> > Try before you buy = See our experts in action!
> > The most comprehensive online learning library for Microsoft developers
> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> > Metro Style Apps, more. Free future releases when you subscribe now!
> > http://p.sf.net/sfu/learndevnow-dev2
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Thanks for posting the link to glumpy.

As Benjamin explained, glumpy servers as a testbed for various technics that could be implemented later in matplotlib. The main problem today is that if you want to benefit from hardware acceleration, you have to use some GL features that are not compatible with he whole matplotlib framework (and we need to ensure some degree of compatibilty). I do not have yet a clean solution and I'm still experimenting.

For your tricontourf problem, I think it might be solved quite easily with the proper GL shader  but I would need a complete (and basic) matplotlib script example to check if this is actually the case.


Nicolas
 


On Jan 27, 2012, at 23:12 , Benjamin Root wrote:

> On Fri, Jan 27, 2012 at 10:06 AM, Howard <ho...@re...> wrote:
> On 1/27/12 3:39 AM, Ian Thomas wrote:
>> 
>> On 26 January 2012 19:36, Howard <ho...@re...> wrote: 
>> I'm rendering some images with about 3.5 million triangles into a 512x512 png file using tricontourf. I'm running this in a virtual machine, and I'm pretty sure that there is no graphics rendering hardware being used. Is it possible, assuming the hardware was available, to make tricontourf use the rendering hardware?  Will that happen by default?
>> 
>> You are correct, there is no graphics hardware rendering.  Rendering is controlled by the various matplotlib backends, and to my knowledge there are  no backends currently available that use hardware rendering.
>> 
>> There has been some work done on an OpenGL backend, but I am not sure of the status of this.  The last time I checked it was pretty experimental.  Perhaps someone involved with it can comment on its current status.
>> 
>> Ian Thomas
> Ian
> 
> Thanks very much for the reply. If it helps whoever is doing the OpenGL backend, I may be able to play with it a bit.
> 
> 
> Howard
> 
> 
> That would be the Glumpy project.
> 
> http://code.google.com/p/glumpy/
> 
> As stated in an email response a while back, glumpy is intended to be a testbed for developing the OpenGL backend for future inclusion into matplotlib.
> 
> Cheers!
> Ben Root
> 
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

I believe that I should terminate this thread (from my side), since the 
image is clear. The actual version of Matplotlib is not adapted to my 
needs, a rather involved animation of many objects, and changing. The 
last dialogue with Benjamin Root, whom I am deeply grateful, cleared my 
doubts. Ben confirms that I am on my own:

> // you need to create your web of callbacks accordingly.  The callback 
> registry is just simply a tool that we created for our use.  Keep in 
> mind that your original question to this thread was "how do I fire 
> events?".  I answered that question a while back.

My question - sorry for being unclear - was how to fire events 
ASYNCHRONOUSLY. How to post them, to be processed by the event loop, not 
how to call callbacks.

>  Ok, but the callback registry is not an event loop.  It is just a 
> callback registry.  The main-loops are in the respective GUI toolkits.

I know that. I read a good part of the matlotlib source, but not all of 
this, since I thought that asking questions might be more efficient.  
And actually it was.

>  There is no event queue in the CallbackRegistry.  What we have done 
> in the respective GUI backends is to link various GUI actions to calls 
> to process().  The CallbackRegistry itself is GUI-neutral and heck, it 
> doesn't even assume a GUI exists, which allows for us to still use the 
> callback registry for other uses in non-interactive modes and headless 
> modes.  Therefore, there is no mainloop, there is no event queue.

This, I believe, is the final answer. Sigh. OK. I am not saved from the 
Pooh syndrome (The more he looked inside the more Piglet wasn't there), 
since now I plan to either code something myself, or to give it as a 
project to my students. I believe that Matplotlib merits this, there is 
plenty of potentialities, but the animation seems to be still in statu 
nascendi.

>   I also noticed that in the example you posted, you created your own 
> callback registry.  Why didn't you use the existing one that comes 
> with the figure canvas?
>
Oh, of course. But this was accidental, it doesn't change anything.

> Quite honestly, I (and I suspect others) are not sure what you are 
> asking of us.  You seem to be quite knowledgeable, but -- quite 
> frankly -- all I see is you complaining about the problem.  /.../ I 
> need you to be very clear about what you want and to exclude any 
> extraneous "rants" you may have.

NO SIR. I am not complaining (cite my "complaints" if you disagree). I 
am trying to find a solution to a problem of delayed, asynchronous event 
processing within Matplotlib. I try to be compact, this is just a 
mailing list. And please: what "rants"??? I would never say anything bad 
about the system nor its authors, I am asking questions. No bugs to 
reports (only that from time to time Python declares some execution 
error of a sub-process, but it may have several sources).

> My only guess is that you were hoping that there was a GUI-neutral 
> mainloop in mpl.  I am sorry to say that one doesn't exist in the 
> manner you are speaking.
Again, this IS the answer. Thank you very much.

================

There is one "rant", if you wish (of course, I am joking).

The animation objects (FuncAnimation, etc.) are coded as they are, 
probably sufficient for you. They are "one shot". But if you want to 
stop and to resume your animation, they are not so well adapted. Calling 
._stop (not documented) from a callback is deadly, because of the 
cleaning procedures. You can't re-_start it. The only way - as I see it 
- is to create another animation. OK, but this might not be the most 
efficient way to do it.

I am afraid that my fascination by Matplotlib, which I really use for my 
teaching of scientific programming and visualization, pushed me to try 
to use the package outside its actual limits. Sorry bor bothering you. 
If I find something of general interest, I will post it, perhaps.

All the best, sincerely.

Jerzy Karczmarczuk
Caen, France

Paul Hobson, on 2012-01-28 23:21,  wrote:
> There is undoubtedly a more efficient way to do this, but give this a shot:
> 
> import numpy as np
> import matplotlib.pyplot as plt
> 
> x = np.arange(0, 10.5, 0.5)
> y = -3.0*x + 0.5*x**2
> 
> color_list = ['FireBrick', 'Orange', 'DarkGreen', 'DarkBlue', 'Indigo']
> limits = np.arange(0, 11, 2)
> fig, ax1 = plt.subplots()
> for n, color in enumerate(color_list):
>     lower = np.where(x >= limits[n])[0]
>     upper = np.where(x <= limits[n+1])[0]
>     index = np.intersect1d(lower, upper)
>     ax1.plot(x[index], y[index], linestyle='-', color=color, linewidth=2)

Another way (if you're ok with only coloring the markers) would
be to use ax1.scatter(x,y,c=colorlist) where the length of all
three arguments is the same. Scatter can do that with the size of
the markers by passing the s= argument.
 
best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 

There is undoubtedly a more efficient way to do this, but give this a shot:

import numpy as np
import matplotlib.pyplot as plt

x = np.arange(0, 10.5, 0.5)
y = -3.0*x + 0.5*x**2

color_list = ['FireBrick', 'Orange', 'DarkGreen', 'DarkBlue', 'Indigo']
limits = np.arange(0, 11, 2)
fig, ax1 = plt.subplots()
for n, color in enumerate(color_list):
    lower = np.where(x >= limits[n])[0]
    upper = np.where(x <= limits[n+1])[0]
    index = np.intersect1d(lower, upper)
    ax1.plot(x[index], y[index], linestyle='-', color=color, linewidth=2)

plt.show()

HTH,
-paul

On Fri, Jan 27, 2012 at 8:12 AM, nahren manuel <mee...@ya...> wrote:
> Dear Users,
> I want to plot a XY, the X-value is constant, but let assume Y varees from
> 1-10, so I want o have different colors accordingly for the range
> 0-2,2-4,4-6,6-8,8-10.
>
> thanks a lot
> najren
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On Sat, Jan 28, 2012 at 4:10 PM, Jerzy Karczmarczuk <
jer...@un...> wrote:

>  Ben Root, about my example in which an infinite callback loop overflows :
>
> So, where is your terminating condition?  Of course it will continuously
> call itself if you have nothing to stop it.  Protect that call to "process"
> with some sort of if-statement and use "evt" to carry some sort of state
> that can be tested in that if-statement.
>
> For example, I modified your example to use "evt" to carry an integer.
>
>
> The program then produces 10 random lines just fine when I press "Go".
>
> Does that help clear up your problem?
>
> No, I am afraid this not the solution, Ben. My program is distilled, the
> truth is more complicated, but I don't need any fixed termination
> condition, this is a simulation program which works continuously until some
> other button invalidates some variable, say "running" (or kills the window,
> etc.). It *should* go forever [of course the real program doesn't pollute
> the axes.lines memory, this is a non-issue].
>

Right, so you need to create your web of callbacks accordingly.  The
callback registry is just simply a tool that we created for our use.  Keep
in mind that your original question to this thread was "how do I fire
events?".  I answered that question a while back.


>
> The issue is that calling a callback from a callback is an abomination in
> general!
>

Then don't do it!  If it happens in mpl, it is rare and well controlled.


>  It should never happen. What SHOULD happen, and takes place in a
> "standard" event loop is that the last line of my procedure "line" is,
> equivalent [simplified] to
>
> if running: push(line,queue)
>
>
> The main loop works as follows:
>
> while notempty(queue):
>   cbak=pop(queue)
>   call(cbak,...)
>
>
> This "distributed loop" may run as long as you wish, no recursion
> overflow, and the possibility to stop it by another callback which assigns
> running=False.
>

Ok, but the callback registry is not an event loop.  It is just a callback
registry.  The main-loops are in the respective GUI toolkits.


>  I repeat that I can in principle write it myself, under ion(), and never
> call show().
> But mainloop() of ANY GUI backend *does already* everything that. But I
> don't know how to find the access to the event queue.
>

There is no event queue in the CallbackRegistry.  What we have done in the
respective GUI backends is to link various GUI actions to calls to
process().  The CallbackRegistry itself is GUI-neutral and heck, it doesn't
even assume a GUI exists, which allows for us to still use the callback
registry for other uses in non-interactive modes and headless modes.
Therefore, there is no mainloop, there is no event queue.


> Under wx, when I write my own loop, there are shortcuts. app.Dispatch()processes the first event in the queue, or waits until something happens.
> Or I call app.ProcessPendingEvents().
>
> My callbacks would call PostEvent(dest, event). The destination is a
> window. I did it some years ago, I don't remember the details, but Post did
> not block anything, returned immediately, and the callback containing it,
> as well. It is possible to Post an event also from another thread, and thus
> faking a Timer.
>

MPL was written with single-threadedness in mind.  There is an example of
multi-processing and mpl, but I don't know how applicable it would be to
you.  I will link it here in case it inspires someone:

http://matplotlib.sourceforge.net/examples/misc/multiprocess.html


> If there were only the "virtual events", I wouldn't bother anybody. But I
> have to deal with all the mouse events as well as with the virtual ones.
> Cumbersome.
>
>
I also noticed that in the example you posted, you created your own
callback registry.  Why didn't you use the existing one that comes with the
figure canvas?

Quite honestly, I (and I suspect others) are not sure what you are asking
of us.  You seem to be quite knowledgeable, but -- quite frankly -- all I
see is you complaining about the problem.  Is there a bug that you wish to
report?  Is there a fundamental design flaw in mpl that you wish to
address?  Or are you confused about how to use the CallbackRegistry?

My only guess is that you were hoping that there was a GUI-neutral mainloop
in mpl.  I am sorry to say that one doesn't exist in the manner you are
speaking.  Each backend communicates with the GUI's mainloop as needed by
the toolkit.  There is no abstracted API for this. Instead, very specific
actions have been created for each backends.  All other actions (like
object picking, changes in the axes and such) are GUI-neutral and do not
need direct interaction with the mainloop (only a call to draw() when
finished).

I really want to help you here, but I need you to be very clear about what
you want and to exclude any extraneous "rants" you may have.

Cheers!
Ben Root

P.S. - Please keep this thread on-list.