Thread: [Matplotlib-users] Exact semantics of ion()??

What does ion() exactly do?  From reading the documentation, I gather that
the interactive mode is equivalent to issuing an automatic draw() after each
plotting comment.  However, a program like the following one does not draw
anything (Matplotlib 1.0, both on Mac OS X and Windows):

>>>
from matplotlib import pyplot as pp

pp.plot([10, 20, 50])
pp.draw()

raw_input('Press enter...')  # No graph displayed?!!
<<<

However, adding ion() and removing the draw() displays the graph.  So, it
looks like the interactive mode does more than what I gather from the docs. 
What does ion() do in addition to adding an automatic draw()?  Can the above
program be modified so as to draw the graph but without using ion()?

Any input would be much appreciated!

EOL

PS: the documentation I was referring to reads: "The interactive property of
the pyplot interface controls whether a figure canvas is drawn on every
pyplot command. If interactive is False, then the figure state is updated on
every plot command, but will only be drawn on explicit calls to draw(). When
interactive is True, then every pyplot command triggers a draw."
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31728909.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Sunday, May 29, 2011, Eric O LEBIGOT (EOL)
<Eri...@no...> wrote:
>
> What does ion() exactly do?  From reading the documentation, I gather that
> the interactive mode is equivalent to issuing an automatic draw() after each
> plotting comment.  However, a program like the following one does not draw
> anything (Matplotlib 1.0, both on Mac OS X and Windows):
>
>>>>
> from matplotlib import pyplot as pp
>
> pp.plot([10, 20, 50])
> pp.draw()
>
> raw_input('Press enter...')  # No graph displayed?!!
> <<<
>
> However, adding ion() and removing the draw() displays the graph.  So, it
> looks like the interactive mode does more than what I gather from the docs.
> What does ion() do in addition to adding an automatic draw()?  Can the above
> program be modified so as to draw the graph but without using ion()?
>
> Any input would be much appreciated!
>
> EOL
>
> PS: the documentation I was referring to reads: "The interactive property of
> the pyplot interface controls whether a figure canvas is drawn on every
> pyplot command. If interactive is False, then the figure state is updated on
> every plot command, but will only be drawn on explicit calls to draw(). When
> interactive is True, then every pyplot command triggers a draw."


Turning interactive mode on also means an implied "show" command, if
needed.  The first program can replace draw() with show().  However,
if interactive mode is off, then the python execution pauses.  With it
on, python execution will continue.

Note, there are some issues with the macosx backend (and it still
exists) with respect to interactive mode.  When on your Mac, you can
use one of the other backends for intended behavior.  Also, there were
a number of additional bug fixes with the backends between 1.0.0 and
1.0.1.


I hope this clears things up,
Ben Root

> --
> View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31728909.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Thank you for your response.


Benjamin Root-2 wrote:
> 
> On Sunday, May 29, 2011, Eric O LEBIGOT (EOL)
> <Eri...@no...> wrote:
>>
>> What does ion() exactly do?
>>$$$
>> from matplotlib import pyplot as pp
>>
>> pp.plot([10, 20, 50])
>> pp.draw()
>>
>> raw_input('Press enter...')  # No graph displayed?!!
>>$$$
> 
> Turning interactive mode on also means an implied "show" command, if
> needed.  The first program can replace draw() with show().  However,
> if interactive mode is off, then the python execution pauses.  With it
> on, python execution will continue.
> 
So, if anything is drawn when interactive mode is off, does one *have* to
use show() at the end?  in other words does using a single raw_input() at
the end of the program force the use of the interactive mode for *all*
figures? (Closing all the figures with a simple "enter" is very convenient,
but having a performance penalty for this would not be so nice…).

Now, if I understand you correctly, I have another question.  I don't
understand anymore what draw() does: in fact, it is not necessary in
interactive mode, and it does not appear to do anything in non-interactive
mode, since show() is really the function that really displays the figures. 
So, why does matplotlib offer draw()?  what does it really do?

EOL

PS: Here is an example: the following code does *not* display the first
figure (Matplotlib 1.0.0 on Mac OS X with the GTKAgg backend):
$$$
from matplotlib import pyplot as pp

pp.figure()
pp.plot([10, 20, 50])
pp.draw()  # Will not be displayed despite the draw()

pp.ion()  # Interactive mode on
pp.figure()
pp.plot([100, 20, 10])

raw_input('Press enter...')  # Only the second graph is displayed
$$$
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31731176.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Monday, May 30, 2011, Eric O LEBIGOT (EOL)
<Eri...@no...> wrote:
>
> Thank you for your response.
>
>
> Benjamin Root-2 wrote:
>>
>> On Sunday, May 29, 2011, Eric O LEBIGOT (EOL)
>> <Eri...@no...> wrote:
>>>
>>> What does ion() exactly do?
>>>$$$
>>> from matplotlib import pyplot as pp
>>>
>>> pp.plot([10, 20, 50])
>>> pp.draw()
>>>
>>> raw_input('Press enter...')  # No graph displayed?!!
>>>$$$
>>
>> Turning interactive mode on also means an implied "show" command, if
>> needed.  The first program can replace draw() with show().  However,
>> if interactive mode is off, then the python execution pauses.  With it
>> on, python execution will continue.
>>
> So, if anything is drawn when interactive mode is off, does one *have* to
> use show() at the end?  in other words does using a single raw_input() at
> the end of the program force the use of the interactive mode for *all*
> figures? (Closing all the figures with a simple "enter" is very convenient,
> but having a performance penalty for this would not be so nice…).
>

Yes, if interactive mode is off, and you want to view the figures, you
need show(). No, the raw_input does nothing in either case.


> Now, if I understand you correctly, I have another question.  I don't
> understand anymore what draw() does: in fact, it is not necessary in
> interactive mode, and it does not appear to do anything in non-interactive
> mode, since show() is really the function that really displays the figures.
> So, why does matplotlib offer draw()?  what does it really do?
>

The draw() command is used for some more advanced features such as
animations and widgets, as well as for internal use.  I rarely use
draw() in my scripts.

May I suggest reading the FAQ and some of the example scripts on the
website in order to demonstrate the different ways to use mpl?

Ben Root


> EOL
>
> PS: Here is an example: the following code does *not* display the first
> figure (Matplotlib 1.0.0 on Mac OS X with the GTKAgg backend):

Off the top of my head, this is either a bug that has been fixed, or
is intended behavior.  Turning interactive mode on after having made a
figure might be confusing pyplot.  Calling show at anytime will
produce the intended behavior.  show() is your friend.



> $$$
> from matplotlib import pyplot as pp
>
> pp.figure()
> pp.plot([10, 20, 50])
> pp.draw()  # Will not be displayed despite the draw()
>
> pp.ion()  # Interactive mode on
> pp.figure()
> pp.plot([100, 20, 10])
>
> raw_input('Press enter...')  # Only the second graph is displayed
> $$$
> --
> View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31731176.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Benjamin Root-2 wrote:
> 
> On Monday, May 30, 2011, Eric O LEBIGOT (EOL)
> <Eri...@no...> wrote:
>>
>> Benjamin Root-2 wrote:
>> So, if anything is drawn when interactive mode is off, does one *have* to
>> use show() at the end?  in other words does using a single raw_input() at
>> the end of the program force the use of the interactive mode for *all*
>> figures? (Closing all the figures with a simple "enter" is very
>> convenient,
>> but having a performance penalty for this would not be so nice…).
>>
> 
> Yes, if interactive mode is off, and you want to view the figures, you
> need show(). No, the raw_input does nothing in either case.
> 
>> Now, if I understand you correctly, I have another question.  I don't
>> understand anymore what draw() does: in fact, it is not necessary in
>> interactive mode, and it does not appear to do anything in
>> non-interactive
>> mode, since show() is really the function that really displays the
>> figures.
>> So, why does matplotlib offer draw()?  what does it really do?
>>
> 
> The draw() command is used for some more advanced features such as
> animations and widgets, as well as for internal use.  I rarely use
> draw() in my scripts.
> 
Thank you for the follow up.

I wish that Matplotlib provided a mechanism for bypassing show(), because
show() is actually not my friend. :-)  In fact, with show(), I hate having
to close one by one each of the 12 figures that my script creates each time
I run it.

The Matplotlib documentation indeed lists many ways to use Matplotlib. 
However, I was trying to get beyond "recipes" and to get a deeper
understanding of what Matplotlib does, so as to avoid wasting too much time
when trying to do something that is not in one of those recipes.  Like
stopping a program that was fully or partially in run in non-interactive
mode, without having to use this dreaded show()…

Thank you again for your input.  It is good to know the limitations of
Matplotlib.  Maybe it is time to suggest the feature I mentioned to the dev
list??
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31734191.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Monday, May 30, 2011, Eric O LEBIGOT (EOL)
<Eri...@no...> wrote:
>
>
> Benjamin Root-2 wrote:
>>
>> On Monday, May 30, 2011, Eric O LEBIGOT (EOL)
>> <Eri...@no...> wrote:
>>>
>>> Benjamin Root-2 wrote:
>>> So, if anything is drawn when interactive mode is off, does one *have* to
>>> use show() at the end?  in other words does using a single raw_input() at
>>> the end of the program force the use of the interactive mode for *all*
>>> figures? (Closing all the figures with a simple "enter" is very
>>> convenient,
>>> but having a performance penalty for this would not be so nice…).
>>>
>>
>> Yes, if interactive mode is off, and you want to view the figures, you
>> need show(). No, the raw_input does nothing in either case.
>>
>>> Now, if I understand you correctly, I have another question.  I don't
>>> understand anymore what draw() does: in fact, it is not necessary in
>>> interactive mode, and it does not appear to do anything in
>>> non-interactive
>>> mode, since show() is really the function that really displays the
>>> figures.
>>> So, why does matplotlib offer draw()?  what does it really do?
>>>
>>
>> The draw() command is used for some more advanced features such as
>> animations and widgets, as well as for internal use.  I rarely use
>> draw() in my scripts.
>>
> Thank you for the follow up.
>
> I wish that Matplotlib provided a mechanism for bypassing show(), because
> show() is actually not my friend. :-)  In fact, with show(), I hate having
> to close one by one each of the 12 figures that my script creates each time
> I run it.
>
> The Matplotlib documentation indeed lists many ways to use Matplotlib.
> However, I was trying to get beyond "recipes" and to get a deeper
> understanding of what Matplotlib does, so as to avoid wasting too much time
> when trying to do something that is not in one of those recipes.  Like
> stopping a program that was fully or partially in run in non-interactive
> mode, without having to use this dreaded show()…
>
> Thank you again for your input.  It is good to know the limitations of
> Matplotlib.  Maybe it is time to suggest the feature I mentioned to the dev
> list??

I am not sure exactly what feature you are asking for.  If you are in
interactive mode, you could setup a key binding to call a function to
close all figures.  Another route to go is to take advantage of
subplots and reduce the number of figures you need to have.

Also, it bares repeating.  You may be experiencing some bugs with
interactive mode in v1.0.0.  Some very important bugfixes were made
wrt interactive mode for the v1.0.1 release.  I know the sourceforge
page still points to v1.0.0, that is a problem that I hope to have
fixed later in the next few days.

Ben Root

> --
> View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31734191.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Benjamin Root-2 wrote:
> 
> On Monday, May 30, 2011, Eric O LEBIGOT (EOL)
>> I wish that Matplotlib provided a mechanism for bypassing show(), because
>> show() is actually not my friend. :-)  In fact, with show(), I hate
>> having
>> to close one by one each of the 12 figures that my script creates each
>> time
>> I run it.
>>
>> (…)
>> stopping a program that was fully or partially in run in non-interactive
>> mode, without having to use this dreaded show()…
>> (…)
> 
> I am not sure exactly what feature you are asking for.  If you are in
> interactive mode, you could setup a key binding to call a function to
> close all figures.  Another route to go is to take advantage of
> subplots and reduce the number of figures you need to have.
> 
The keybinding idea is interesting, but the goal is to work in
*non*-interactive mode (for optimization purposes), and the feature I would
love is simply to be able to display graphs in this mode without using
show().  Subplots are unfortunately not an option for me, as each of the
numerous graph must be independent (they are each saved in a specific file).


Benjamin Root-2 wrote:
> 
> Also, it bares repeating.  You may be experiencing some bugs with
> interactive mode in v1.0.0.  Some very important bugfixes were made
> wrt interactive mode for the v1.0.1 release.  I know the sourceforge
> page still points to v1.0.0, that is a problem that I hope to have
> fixed later in the next few days.
> 
Thanks, I'll definitely check out version 1.0.1.  The feature I wish existed
is unfortunately relevant to the *non*-interactive mode.

-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31734671.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On 05/30/2011 06:42 AM, Eric O LEBIGOT (EOL) wrote:
>
>
> Benjamin Root-2 wrote:
>>
>> On Monday, May 30, 2011, Eric O LEBIGOT (EOL)
>>> I wish that Matplotlib provided a mechanism for bypassing show(), because
>>> show() is actually not my friend. :-)  In fact, with show(), I hate
>>> having
>>> to close one by one each of the 12 figures that my script creates each
>>> time
>>> I run it.
>>>
>>> (…)
>>> stopping a program that was fully or partially in run in non-interactive
>>> mode, without having to use this dreaded show()…
>>> (…)
>>
>> I am not sure exactly what feature you are asking for.  If you are in
>> interactive mode, you could setup a key binding to call a function to
>> close all figures.  Another route to go is to take advantage of
>> subplots and reduce the number of figures you need to have.
>>
> The keybinding idea is interesting, but the goal is to work in
> *non*-interactive mode (for optimization purposes), and the feature I would
> love is simply to be able to display graphs in this mode without using
> show().  Subplots are unfortunately not an option for me, as each of the
> numerous graph must be independent (they are each saved in a specific file).

Is it correct that you want interactive mode, except that you want to 
control when drawing occurs, for purposes of efficiency?  If so, use 
interactive mode, but instead of using the pyplot interface for the 
actual plotting, use the OO interface, and call plt.draw() when you want 
to update a plot.  See
http://matplotlib.sourceforge.net/faq/usage_faq.html#matplotlib-pylab-and-pyplot-how-are-they-related
although this does not give precisely the example to match your case.

Eric

>
>
> Benjamin Root-2 wrote:
>>
>> Also, it bares repeating.  You may be experiencing some bugs with
>> interactive mode in v1.0.0.  Some very important bugfixes were made
>> wrt interactive mode for the v1.0.1 release.  I know the sourceforge
>> page still points to v1.0.0, that is a problem that I hope to have
>> fixed later in the next few days.
>>
> Thanks, I'll definitely check out version 1.0.1.  The feature I wish existed
> is unfortunately relevant to the *non*-interactive mode.
>

efiring wrote:
> 
> Is it correct that you want interactive mode, except that you want to 
> control when drawing occurs, for purposes of efficiency?
Thank you for your interest in this question, Eric!

The goal is to indeed control when drawing occurs, but also to not use
show() (because it cumbersome to have to close umpteen windows so as to
finish a Matplotlib program that opened lots of figures). (I checked the
examples that you referred to)

It looks like Matplotlib forces either to use the interactive mode (possibly
inefficient) or to use show() (possibly cumbersome).  I wish that Matplotlib
offers an alternative to this situation, but this looks less and less to be
the case.  That's something I would like to suggest to the devs.
:-)
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31735322.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL) <
Eri...@no...> wrote:

>
>
> efiring wrote:
> >
> > Is it correct that you want interactive mode, except that you want to
> > control when drawing occurs, for purposes of efficiency?
> Thank you for your interest in this question, Eric!
>
> The goal is to indeed control when drawing occurs, but also to not use
> show() (because it cumbersome to have to close umpteen windows so as to
> finish a Matplotlib program that opened lots of figures). (I checked the
> examples that you referred to)
>
> It looks like Matplotlib forces either to use the interactive mode
> (possibly
> inefficient) or to use show() (possibly cumbersome).  I wish that
> Matplotlib
> offers an alternative to this situation, but this looks less and less to be
> the case.  That's something I would like to suggest to the devs.
> :-)
>

Question: would displaying a figure (or a group of figures), pausing to let
you close them, and then continuing to the next figures more along the lines
of what you want?  That is certainly possible with matplotlib.  Since
v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
for certain backends to do this correctly).

Furthermore, I think Eric Firing's point was that mpl is fully capable of
doing what you want.  The automatic draws are only done if the calls come
through pyplot or pylab and if interactive mode is on.  There might be a few
minor exceptions to this rule, but those shouldn't cause significant
overhead.  If you call the drawing commands directly, then a refresh does
not occur until you tell it to with a call to draw().  In pyplot, nearly all
drawing commands have as the final step a call to a function called
"draw_if_interactive()".  This function does exactly what it says.
Therefore, if you want interactive mode, but do not want a refresh after
each pyplot command, then don't use the pyplot commands!  Just use the
objects' drawing commands (which is what pyplot calls).

Also, note that matplotlib is hierarchical.  You could call directly call
draw() on each object you want re-drawn, but you don't have to.  You can
give a single call to a parent object that would call draw() for all of its
children objects.  So, a figure object has (among other things) axes objects
as children.  An axes object has (among other things) various collection
objects from the plotting commands as its children.  Maybe a look at some of
the animation examples might be a good way to illustrate this.  I would
suggest looking at the older animation examples on sourceforge where the
internals are all laid out.

I hope this is helpful,
Ben Root

I really appreciate your continuing this discussion, Ben.

Benjamin Root-2 wrote:
> 
> On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL) <
> Eri...@no...> wrote:
> Question: would displaying a figure (or a group of figures), pausing to
> let
> you close them, and then continuing to the next figures more along the
> lines
> of what you want?  That is certainly possible with matplotlib.  Since
> v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
> for certain backends to do this correctly).
> 
Yeah, the new show() is nice.  However, I don't want my users to have to
close the numerous opened figures one by one, even if it is done in 4 times
3 clicks (and, again, it would not be convenient to put the graphs in
subplots).  So, what I am really looking for is really: (1) display figures
without having to use show(); and (2) do this efficiently (without automatic
drawing through the interactive mode).


Benjamin Root-2 wrote:
> 
> (…) In pyplot, nearly all
> drawing commands have as the final step a call to a function called
> "draw_if_interactive()".
> (…)
> You could call directly call
> draw() on each object you want re-drawn, but you don't have to.  You can
> give a single call to a parent object that would call draw() for all of
> its
> children objects.
> (…)
> 
Thank you for these more theoretical explanations, which are interesting.

However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
backend), or 1.0.0 Mac OS X (default backend and GTKAgg).  The main problem
is that draw() does unfortunately not draw anything in non-interactive mode
(this happens when there is no show() in the code)!  So, with these two
recent version, in *non*-interactive mode, it does not appear that "a
refresh does not occur until you tell it to with a call to draw()", and
things like this.  There is no refresh at all, and pyplot.draw() does
display anything (this is illustrated by the last program example I posted). 
As far as I can see, theory and practice strongly clash, about the
"refreshing" effect of the draw() command (in non-interactive mode), as I
can't see anything being refreshed or displayed by draw.  What is your take
on this?

Thank you for the idea of bypassing pyplot's automatic update in interactive
mode.  How is this done?  Doing ax.draw(ax.figure.canvas.renderer) raises a
RunTime error with the default Mac OS X backend, and an AttributeError with
the GTKAgg backend.  How should the draw() method of Matplotlib objects be
called?

Now that I'm thinking of it, the crux of the problem might be that
pyplot.figure() does *not* open any window, in non-interactive mode (until
show() is called, which I want to avoid).  This looks like a bad start if
draw() is to refresh anything…  Could this be the main stumbling block?  Can
a new window be opened in non-interactive mode (without using show())?
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31738725.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On 05/30/2011 09:59 PM, Eric O LEBIGOT (EOL) wrote:
>
> I really appreciate your continuing this discussion, Ben.
>
> Benjamin Root-2 wrote:
>>
>> On Mon, May 30, 2011 at 3:11 PM, Eric O LEBIGOT (EOL)<
>> Eri...@no...>  wrote:
>> Question: would displaying a figure (or a group of figures), pausing to
>> let
>> you close them, and then continuing to the next figures more along the
>> lines
>> of what you want?  That is certainly possible with matplotlib.  Since
>> v1.0.0, multiple calls to show() is allowed (although you may need v1.0.1
>> for certain backends to do this correctly).
>>
> Yeah, the new show() is nice.  However, I don't want my users to have to
> close the numerous opened figures one by one, even if it is done in 4 times
> 3 clicks (and, again, it would not be convenient to put the graphs in
> subplots).  So, what I am really looking for is really: (1) display figures
> without having to use show(); and (2) do this efficiently (without automatic
> drawing through the interactive mode).
>
>
> Benjamin Root-2 wrote:
>>
>> (…) In pyplot, nearly all
>> drawing commands have as the final step a call to a function called
>> "draw_if_interactive()".
>> (…)
>> You could call directly call
>> draw() on each object you want re-drawn, but you don't have to.  You can
>> give a single call to a parent object that would call draw() for all of
>> its
>> children objects.
>> (…)
>>
> Thank you for these more theoretical explanations, which are interesting.
>
> However, they do not seem to apply to Matplotlib 1.0.1 on Windows (default
> backend), or 1.0.0 Mac OS X (default backend and GTKAgg).  The main problem
> is that draw() does unfortunately not draw anything in non-interactive mode
> (this happens when there is no show() in the code)!  So, with these two
> recent version, in *non*-interactive mode, it does not appear that "a
> refresh does not occur until you tell it to with a call to draw()", and
> things like this.  There is no refresh at all, and pyplot.draw() does
> display anything (this is illustrated by the last program example I posted).
> As far as I can see, theory and practice strongly clash, about the
> "refreshing" effect of the draw() command (in non-interactive mode), as I
> can't see anything being refreshed or displayed by draw.  What is your take
> on this?
>
> Thank you for the idea of bypassing pyplot's automatic update in interactive
> mode.  How is this done?  Doing ax.draw(ax.figure.canvas.renderer) raises a
> RunTime error with the default Mac OS X backend, and an AttributeError with
> the GTKAgg backend.  How should the draw() method of Matplotlib objects be
> called?
>
> Now that I'm thinking of it, the crux of the problem might be that
> pyplot.figure() does *not* open any window, in non-interactive mode (until
> show() is called, which I want to avoid).  This looks like a bad start if
> draw() is to refresh anything…  Could this be the main stumbling block?  Can
> a new window be opened in non-interactive mode (without using show())?

Stop saying you want to avoid show(); let's just figure out how to get 
to the desired end result.  You probably *need* to use show; with 1.0.1 
in interactive mode, it will not block.  Your script can close the 
windows; your user doesn't have to do so manually.

It sounds like you are indeed talking about a free-standing script, that 
is, not involving ipython or other intermediate shell, correct?

Can you come up with a minimal example of what you want it to do, and 
how you want the user to be able to interact with it?  Does the attached 
script illustrate something roughly like what you are trying to do?

Eric

efiring wrote:
> 
> Stop saying you want to avoid show(); (…).  You probably *need* to use
> show; with 1.0.1 
> in interactive mode, it will not block.  Your script can close the 
> windows; your user doesn't have to do so manually.
> 
You are right: your script shows that the latest (1.0.1) show() is great, as
it is non-blocking in interactive mode (except with the macosx backend). 
(It is the pre-1.0.1 blocking show() that was not a solution.)


efiring wrote:
> 
> It sounds like you are indeed talking about a free-standing script, that 
> is, not involving ipython or other intermediate shell, correct?
> 
Correct.


efiring wrote:
> 
> Does the attached 
> script illustrate something roughly like what you are trying to do?
> 
Yes, it does, thanks.  Just a detail: since the interactive mode is on, the
plt.draw()s in the second part are not necessary, are they?

So, to summarize, the latest 1.0.1 show() does the actual drawing (not
draw()), is non-blocking in interactive mode, and can be called multiple
times.  This is both convenient (no need to manually close umpteen windows
one by one), and efficient (non interactive mode can be used up until show()
is called).  Thus, the practical side of the problem is closed: thanks!

I have been asking these questions because I have been using and teaching
(Python and) Matplotlib for 3 years, now, to students who use a variety of
OSes, so I wanted to get things straight.

On the "theoretical" side, draw() is actually rarely used for drawing or
refreshing simple figures (including common non-animated figures), but is
more for "some more advanced features such as animations and widgets, as
well as for internal use.", as Ben was writing, right?  And show() is really
the function that commonly does the actual display or refresh, right?  If
this is correct, I will be done with my questions.
:-)

-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31739359.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

One-line correction to script attached to last post; so use the one 
attached here.

On 05/30/2011 11:42 PM, Eric O LEBIGOT (EOL) wrote:
>
>
> efiring wrote:
>>
>> Stop saying you want to avoid show(); (…).  You probably *need* to use
>> show; with 1.0.1

The above was wrong--see below.  If you start with interactive mode on, 
you do not need show at all.  In non-interactive mode, you do need show.

>> in interactive mode, it will not block.  Your script can close the
>> windows; your user doesn't have to do so manually.
>>
> You are right: your script shows that the latest (1.0.1) show() is great, as
> it is non-blocking in interactive mode (except with the macosx backend).
> (It is the pre-1.0.1 blocking show() that was not a solution.)
>
>
> efiring wrote:
>>
>> It sounds like you are indeed talking about a free-standing script, that
>> is, not involving ipython or other intermediate shell, correct?
>>
> Correct.
>
>
> efiring wrote:
>>
>> Does the attached
>> script illustrate something roughly like what you are trying to do?
>>
> Yes, it does, thanks.  Just a detail: since the interactive mode is on, the
> plt.draw()s in the second part are not necessary, are they?

Not a detail: you do need the draw if you are not ending with a pyplot 
function, as opposed to an object method.  You could just use the pyplot 
function, plt.plot(), instead of the method, ax.plot(), etc., which 
would call the draw automatically.

Now, you may find that everything works the same if you eliminate the 
first draw in my example; that is because the plt.figure() call has put 
a draw request in to the gui toolkit, and the toolkit is not executing 
it right away.  Don't rely on this, however; if you are using the object 
methods, call draw when you want the figure to be refreshed.

>
> So, to summarize, the latest 1.0.1 show() does the actual drawing (not
> draw()), is non-blocking in interactive mode, and can be called multiple
> times.  This is both convenient (no need to manually close umpteen windows
> one by one), and efficient (non interactive mode can be used up until show()
> is called).  Thus, the practical side of the problem is closed: thanks!

Not quite. Draw() ensures that everything is up to date; show() is not a 
direct substitute.

In my example script, I should have put the call to plt.ion() *before* 
all other pyplot calls. If you do that, then you actually don't need the 
show() at all, because the the initial call to plt.figure() in 
interactive mode displays the figure.


>
> I have been asking these questions because I have been using and teaching
> (Python and) Matplotlib for 3 years, now, to students who use a variety of
> OSes, so I wanted to get things straight.
>
> On the "theoretical" side, draw() is actually rarely used for drawing or
> refreshing simple figures (including common non-animated figures), but is
> more for "some more advanced features such as animations and widgets, as
> well as for internal use.", as Ben was writing, right?  And show() is really
> the function that commonly does the actual display or refresh, right?  If
> this is correct, I will be done with my questions.
> :-)
>

No, if you use object methods rather than the pyplot interface, then you 
need to use draw().  For example, if you try changing the last draw() in 
my example to a show(), the new line will not be added.

Eric

Thank you for these precisions.

I think I'm starting to see more clearly what the
interactive/non-interactive modes do with pyplot commands (plot(), draw(),
show(),…), and with draw() methods.

There is only one thing that I'm not sure about: if we look at your script
and leave the ion() were you left it, shouldn't an ax.draw() be called just
before the ion()?  (I indeed understand from your last post that one "should
not rely" on "pyplot.figure()" sending a delayed draw() request to the GUI.)

So, to summarize the whole discussion:

* Interactive mode:

- Graph elements plotted with *pyplot* commands (not Matplotlib object
methods) are displayed without the need to use draw() or show().

- However, plots done through Matplotlib objects (like Axes) are normally
not displayed (even though they may be, with some backends).  The actual
display of such plots is done through their draw() method (or possibly
pyplot.draw()).  This feature might be used for optimization purposes (a
graph can be refreshed on screen once even though multiple updates were
performed on it through Matplotlib object method calls).

- show(), if used, is non-blocking.  It displays everything that was drawn()
(for instance figures that were created in non-interactive mode).  Things
that were not drawn() might be displayed by some backends, but one should
not rely on this.

* Non-interactive mode

- No figure or graph is displayed and/or refreshed automatically.  This is
useful for optimization purposes, when a graph is updated many times before
it reaches its final state (modification of some elements, like changing a
color, etc.).

- show() displays all the drawn() elements and is blocking.  It is possible
to switch temporarily to interactive mode in order to make it non-blocking.

=> Is this correct?  are there other issues that could be important for
students (and myself!) to grasp so that they use Matplotlib as best as
possible?
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31748057.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

PS: One could add to the non-interactive mode part that "pyplot.draw()" has
the same effect as drawing() everything (normally, this does not display
anything, but is necessary so that show() displays the drawn() elements). 
Right?
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31748078.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst

Eric, Ben,

See if the section "What is interactive mode" makes sense to you.  I 
have just added it to a feature branch (which includes some other faq 
madifications, mainly moving the backend section from installation to 
usage), but have not yet generated a pull request.  It doesn't go into 
every detail, or into the underlying machinery.  It is intended to 
provide just enough understanding to clear up user-level confusion about 
interactive mode, show, and draw, and let most relatively new users get 
on with their work.

Eric

On Saturday, June 4, 2011, Eric Firing <ef...@ha...> wrote:
>
>
> https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst
>
> Eric, Ben,
>
> See if the section "What is interactive mode" makes sense to you.  I have just added it to a feature branch (which includes some other faq madifications, mainly moving the backend section from installation to usage), but have not yet generated a pull request.  It doesn't go into every detail, or into the underlying machinery.  It is intended to provide just enough understanding to clear up user-level confusion about interactive mode, show, and draw, and let most relatively new users get on with their work.
>
> Eric
>

Eric,

I see where you are going with this, and this is valuable information
to include in the docs. However, the interactive mode and backend info
doesn't seem to fit properly with everything else on the page.  I am
not sure where to put them yet, but I will see if I can take a deeper
look tomorrow.  I also already noticed some other wording issues in
some other parts of that page.

Ben Root

On 06/07/2011 11:46 AM, Benjamin Root wrote:
> On Saturday, June 4, 2011, Eric Firing<ef...@ha...>  wrote:
>>
>>
>> https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst
>>
>> Eric, Ben,
>>
>> See if the section "What is interactive mode" makes sense to you.  I have just added it to a feature branch (which includes some other faq madifications, mainly moving the backend section from installation to usage), but have not yet generated a pull request.  It doesn't go into every detail, or into the underlying machinery.  It is intended to provide just enough understanding to clear up user-level confusion about interactive mode, show, and draw, and let most relatively new users get on with their work.
>>
>> Eric
>>
>
> Eric,
>
> I see where you are going with this, and this is valuable information
> to include in the docs. However, the interactive mode and backend info
> doesn't seem to fit properly with everything else on the page.  I am

I don't see why not.  A FAQ is a place for answers to questions, and 
this is the usage section of the FAQ, so I don't see any inherent reason 
why information about backends and interactive mode, both of which 
involve mpl usage, can't go there.  There may be better places, to which 
the FAQ could refer, but I think the FAQ is better than nothing.  I 
moved the backend piece from the installation part of the FAQ, where it 
*really* didn't belong.  (And the remaining installation part is also an 
out-of-date worm jar.)

> not sure where to put them yet, but I will see if I can take a deeper
> look tomorrow.  I also already noticed some other wording issues in
> some other parts of that page.
>
> Ben Root

What you will also find is that the section users/shell.rst, which threw 
Eric L for a loop in the first place, badly needs updating, and overlaps 
with what I was trying to do in the FAQ.  As Eric also points out, a 
section with more detail would probably be good somewhere; I was 
thinking of putting that in the FAQ also, at least as a first step.

My github branch now includes a changeset with augmented docstrings for 
show and draw.

Eric

On Tuesday, June 7, 2011, Eric Firing <ef...@ha...> wrote:
> On 06/07/2011 11:46 AM, Benjamin Root wrote:
>> On Saturday, June 4, 2011, Eric Firing<ef...@ha...>  wrote:
>>>
>>>
>>> https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst
>>>
>>> Eric, Ben,
>>>
>>> See if the section "What is interactive mode" makes sense to you.  I have just added it to a feature branch (which includes some other faq madifications, mainly moving the backend section from installation to usage), but have not yet generated a pull request.  It doesn't go into every detail, or into the underlying machinery.  It is intended to provide just enough understanding to clear up user-level confusion about interactive mode, show, and draw, and let most relatively new users get on with their work.
>>>
>>> Eric
>>>
>>
>> Eric,
>>
>> I see where you are going with this, and this is valuable information
>> to include in the docs. However, the interactive mode and backend info
>> doesn't seem to fit properly with everything else on the page.  I am
>
> I don't see why not.  A FAQ is a place for answers to questions, and
> this is the usage section of the FAQ, so I don't see any inherent reason
> why information about backends and interactive mode, both of which
> involve mpl usage, can't go there.  There may be better places, to which
> the FAQ could refer, but I think the FAQ is better than nothing.  I
> moved the backend piece from the installation part of the FAQ, where it
> *really* didn't belong.  (And the remaining installation part is also an
> out-of-date worm jar.)
>
>> not sure where to put them yet, but I will see if I can take a deeper
>> look tomorrow.  I also already noticed some other wording issues in
>> some other parts of that page.
>>
>> Ben Root
>
> What you will also find is that the section users/shell.rst, which threw
> Eric L for a loop in the first place, badly needs updating, and overlaps
> with what I was trying to do in the FAQ.  As Eric also points out, a
> section with more detail would probably be good somewhere; I was
> thinking of putting that in the FAQ also, at least as a first step.
>
> My github branch now includes a changeset with augmented docstrings for
> show and draw.
>
> Eric
>

I think my main issue is that the FAQ is not really an FAQ anymore.
There are only a few remaining questions as section headers, and some
of the "answers" are much too involved.  I would think we would be
best served by a real FAQ and then separate topic-based docs that the
answers can link to (as well as having them accessible from the main
toc).

Ben Root

efiring wrote:
> 
> My github branch now includes a changeset with augmented docstrings for 
> show and draw.
> 
Your new docstrings are a great improvement.  They answer many of the
questions I have been having for years.

As for where the interactive mode/non-interactive mode discussion should be,
I think that while the mere existence of this discussion is an improvement. 
I vote for moving it to a more prominent place than the FAQ, as it is about
an important, practical subject that users should be aware of quite early
when they learn Matplotlib.

Anyway, many thanks to you and Ben for devoting time to this.
:-)
-- 
View this message in context: http://old.nabble.com/Exact-semantics-of-ion%28%29---tp31728909p31798588.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Tue, Jun 7, 2011 at 5:01 PM, Eric Firing <ef...@ha...> wrote:

> On 06/07/2011 11:46 AM, Benjamin Root wrote:
> > On Saturday, June 4, 2011, Eric Firing<ef...@ha...>  wrote:
> >>
> >>
> >>
> https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst
> >>
> >> Eric, Ben,
> >>
> >> See if the section "What is interactive mode" makes sense to you.  I
> have just added it to a feature branch (which includes some other faq
> madifications, mainly moving the backend section from installation to
> usage), but have not yet generated a pull request.  It doesn't go into every
> detail, or into the underlying machinery.  It is intended to provide just
> enough understanding to clear up user-level confusion about interactive
> mode, show, and draw, and let most relatively new users get on with their
> work.
> >>
> >> Eric
> >>
> >
> > Eric,
> >
> > I see where you are going with this, and this is valuable information
> > to include in the docs. However, the interactive mode and backend info
> > doesn't seem to fit properly with everything else on the page.  I am
>
> I don't see why not.  A FAQ is a place for answers to questions, and
> this is the usage section of the FAQ, so I don't see any inherent reason
> why information about backends and interactive mode, both of which
> involve mpl usage, can't go there.  There may be better places, to which
> the FAQ could refer, but I think the FAQ is better than nothing.  I
> moved the backend piece from the installation part of the FAQ, where it
> *really* didn't belong.  (And the remaining installation part is also an
> out-of-date worm jar.)
>

I am looking at doc/faq/installing_faq.rst on your branch, and I can't tell
what is out-of-date (although the Mac part might be, I don't know).  If you
are referring to doc/users/installing.rst, that should have been removed in
the big set of commits I made recently when I merged from v1.0.x-maint to
master (the INSTALL file is now used in master for the installation docs).

The problem I do see with installation_faq.rst is that the section titles
are not questions, but that is a minor issue here.

Ben Root

On 06/09/2011 09:45 AM, Benjamin Root wrote:
>
>
> On Tue, Jun 7, 2011 at 5:01 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
>     On 06/07/2011 11:46 AM, Benjamin Root wrote:
>      > On Saturday, June 4, 2011, Eric Firing<ef...@ha...
>     <mailto:ef...@ha...>>  wrote:
>      >>
>      >>
>      >>
>     https://github.com/efiring/matplotlib/blob/faq_show_draw/doc/faq/usage_faq.rst
>      >>
>      >> Eric, Ben,
>      >>
>      >> See if the section "What is interactive mode" makes sense to
>     you.  I have just added it to a feature branch (which includes some
>     other faq madifications, mainly moving the backend section from
>     installation to usage), but have not yet generated a pull request.
>       It doesn't go into every detail, or into the underlying machinery.
>       It is intended to provide just enough understanding to clear up
>     user-level confusion about interactive mode, show, and draw, and let
>     most relatively new users get on with their work.
>      >>
>      >> Eric
>      >>
>      >
>      > Eric,
>      >
>      > I see where you are going with this, and this is valuable information
>      > to include in the docs. However, the interactive mode and backend
>     info
>      > doesn't seem to fit properly with everything else on the page.  I am
>
>     I don't see why not.  A FAQ is a place for answers to questions, and
>     this is the usage section of the FAQ, so I don't see any inherent reason
>     why information about backends and interactive mode, both of which
>     involve mpl usage, can't go there.  There may be better places, to which
>     the FAQ could refer, but I think the FAQ is better than nothing.  I
>     moved the backend piece from the installation part of the FAQ, where it
>     *really* didn't belong.  (And the remaining installation part is also an
>     out-of-date worm jar.)
>
>
> I am looking at doc/faq/installing_faq.rst on your branch, and I can't
> tell what is out-of-date (although the Mac part might be, I don't
> know).  If you are referring to doc/users/installing.rst, that should
> have been removed in the big set of commits I made recently when I
> merged from v1.0.x-maint to master (the INSTALL file is now used in
> master for the installation docs).

Ben,

I am referring to doc/faq/installing_faq.rst, and I am mainly concerned 
about the OS-X section.  The version references are clearly out of date; 
as for the rest, I have no idea what actually works and should be 
recommended.  Attempts have been made elsewhere in mpl to update and 
clarify the OS-X build and install situation, but I don't think any of 
that is reflected in this faq section, and I would not be surprised if 
there are other places in the overall mpl tree where OS-X confusion 
still lurks.  Certainly the mailing list indicates that OS-X 
installation and building has been a frequent sore point.  Although I 
have built and installed mpl on an OS-X machine, I don't normally use 
one, and I certainly don't understand all the arcane variables and 
variations.

In OS-X and elsewhere I would also raise the question: does easy-install 
have a high enough success rate with mpl that it should be included as a 
reasonable option?  Or should its use for mpl be discouraged? I don't 
know the answer, and have never tried easy-install with mpl, but in 
general I don't trust it.  Too much behind-the-scenes magic.

And the users/installing.rst has problems, too, in addition to the 
general problem of information about building and installing being 
scattered among the users section, the faq, INSTALL, make.osx, and 
setup*.  Small example: installation requirements are listed under the 
heading "Build requirements".

Progress is going to have to be incremental; I doubt that anyone will 
have the time to go through the whole system and really clean everything 
up in one pass.

I suggest, if you don't mind, that I go ahead and merge my branch into 
maint (and from there, master), and then the next increment, whether by 
you, me, or someone else, can be in a new branch, and the process can be 
repeated.

Eric

>
> The problem I do see with installation_faq.rst is that the section
> titles are not questions, but that is a minor issue here.
>
> Ben Root
>