[IPython-User] what triggers a figure redraw / inline

[John Hunter-4]

I am working on a notebook and want to build up a figure in stages to illustrate the effect of successive code blocks.  After the first code cell, the figure is drawn and inlined, as expected.  After the second, no figure is inserted, even if I try and force it to with "draw".  How are you deciding whether to insert a figure or not, and is there a way to force the figure redraw inline?

BTW< I am using ipython from git HEAD and the new UI is *fantastic*.  Very nice work, and very exciting!

# -*- coding: utf-8 -*-

# <nbformat>3</nbformat>

# <codecell>

import numpy as np

import matplotlib.pyplot as plt

# the random data

x = np.random.randn(1000)

y = np.random.randn(1000)

fig = plt.figure(1, figsize=(5.5,5.5))

from mpl_toolkits.axes_grid1 import make_axes_locatable

# the scatter plot:

axScatter = plt.subplot(111)

axScatter.scatter(x, y)

axScatter.set_aspect(1.)

# <markdowncell>

# <h1> Make the axes dividable </h1>

# Create new axes on the right and on the top of the current axes

# The first argument of the new_vertical(new_horizontal) method is

# the height (width) of the axes to be created in inches.

# <codecell>

binwidth = 0.25

xymax = np.max( [np.max(np.fabs(x)), np.max(np.fabs(y))] )

lim = ( int(xymax/binwidth) + 1) * binwidth

bins = np.arange(-lim, lim + binwidth, binwidth)

divider = make_axes_locatable(axScatter)

axHistx = divider.append_axes("top", 1.2, pad=0.1, sharex=axScatter)

bins = np.arange(-lim, lim + binwidth, binwidth)

axHistx.hist(x, bins=bins);

plt.draw()

# <codecell>

_______________________________________________
IPython-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-user

[Fernando Perez]

Hey John,

On Thu, Feb 23, 2012 at 11:11 AM, John Hunter <[hidden email]> wrote:
> I am working on a notebook and want to build up a figure in stages to
> illustrate the effect of successive code blocks.  After the first code cell,
> the figure is drawn and inlined, as expected.  After the second, no figure
> is inserted, even if I try and force it to with "draw".  How are you
> deciding whether to insert a figure or not, and is there a way to force the
> figure redraw inline?

The default behavior is to close the figures once they have been
created.  But you have two ways to go about this:

Option #1. Since you're already keeping a reference to your figure (ps
- shame on you for still advertising the god-forsaken .subplot(111)
syntax ;):

> fig = plt.figure(1, figsize=(5.5,5.5))

you can simply in your second cell return the figure as the very last
line of the second cell, or call display() on it.  That is, replace
this:

> plt.draw()

with

fig

or

display(fig)

The difference of the second form is that it will work even if it's
not the last line, where as simply causing the fig repr to trigger a
display only happens if it's the last item.  It also keeps a reference
to the figure since it produces an Out[] cell.


Option #2: you can change the closing behavior of the inline backend,
either for this notebook:

%config InlineBackend.close_figures = False

or permanently in your config file.  At that point, figures remain
open and you're responsible for manually closing them, but this lets
you build a figure incrementally cell after cell.  You can then
display it at the end either with display() or force all figures to
show with plt.show() at the end of a cell, just as if it was a script.


> BTW< I am using ipython from git HEAD and the new UI is *fantastic*.  Very
> nice work, and very exciting!

Yes, it's looking great.  If it weren't for the Strata/pydata/pycon
madness we might have been able to push a formal 0.13 release already
with all that, but it will need to wait a few weeks.

Cheers,

f
_______________________________________________
IPython-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-user

[John Hunter-4]

On Thu, Feb 23, 2012 at 2:43 PM, Fernando Perez <[hidden email]> wrote:

Hey John,

On Thu, Feb 23, 2012 at 11:11 AM, John Hunter <[hidden email]> wrote:
> I am working on a notebook and want to build up a figure in stages to
> illustrate the effect of successive code blocks.  After the first code cell,
> the figure is drawn and inlined, as expected.  After the second, no figure
> is inserted, even if I try and force it to with "draw".  How are you
> deciding whether to insert a figure or not, and is there a way to force the
> figure redraw inline?

The default behavior is to close the figures once they have been
created.  But you have two ways to go about this:

Option #1. Since you're already keeping a reference to your figure (ps
- shame on you for still advertising the god-forsaken .subplot(111)
syntax ;):

My bad -- I was translating this example 

http://matplotlib.sourceforge.net/examples/axes_grid/scatter_hist.html

 

which may have pre-dated your much superior "plt.subplots".  Fixed now.  Incidentally, I was thinking about presenting this example in a talk, and was contemplating cutting-and-pasting the code into a standard ipython terminal piece by piece to illustrate the effect of each axes divider call (like an hbox or vbox for mpl figures, thanks JJ).  The for loops near the end:

  for tl in axHistx.get_xticklabels():

      tl.set_visible(False)

  axHistx.set_yticks([0, 50, 100])

are not friendly to paste into ipython terminal shells because they do not have the blank line after the indent.  Then I realized, aha, this is precisely what the notebook excels at: building up a code example with multi-line input in chunks.

 

you can simply in your second cell return the figure as the very last
line of the second cell, or call display() on it.  That is, replace
this:

> plt.draw()

with

fig

or

display(fig)

This works great for my use case; I will play with the config parameters later.  Thanks for the tips.

JDH

_______________________________________________
IPython-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-user

[Thomas Kluyver-2]

On 23 February 2012 21:31, John Hunter <[hidden email]> wrote:
> The for loops near the end:
>
>   for tl in axHistx.get_xticklabels():
>       tl.set_visible(False)
>   axHistx.set_yticks([0, 50, 100])
>
> are not friendly to paste into ipython terminal shells because they do not
> have the blank line after the indent

Note that you can use %paste to run code from the clipboard. But I
agree that the notebook is a much better interface for demos.

Thomas
_______________________________________________
IPython-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-user

[Fernando Perez]

On Thu, Feb 23, 2012 at 1:31 PM, John Hunter <[hidden email]> wrote:
>
> My bad -- I was translating this example
>
> http://matplotlib.sourceforge.net/examples/axes_grid/scatter_hist.html
>
> which may have pre-dated your much superior "plt.subplots".  Fixed now.

Ahh, I can breathe better already :)  Speaking of the gallery (this is
getting OT for ipython), I think it's in serious need of a cleanup.  I
appreciate today's PR on organizing it by sections, but the real issue
is that over the years, the gallery has accrued a lot of scripts
without any comments or explanations of purpose, deprecated APIs, etc.
 I wonder if you could spur a 'gallery cleanup' project, encouraging
users to submit pull requests that remove duplicate/similar examples,
document better the ones left, etc.  While there's a lot of good stuff
there and I continue to point people to it, there really is also a
massive amount of weed growth that is starting to be annoying in
practice.

But the cleanup job is easy, can be done by non-experts (and is hence
a great one for new developers to start contributing) and would be
very beneficial to the project at large.

>  Incidentally, I was thinking about presenting this example in a talk, and
> was contemplating cutting-and-pasting the code into a standard ipython
> terminal piece by piece to illustrate the effect of each axes divider call
> (like an hbox or vbox for mpl figures, thanks JJ).  The for loops near the
> end:
>
>   for tl in axHistx.get_xticklabels():
>       tl.set_visible(False)
>   axHistx.set_yticks([0, 50, 100])
>
> are not friendly to paste into ipython terminal shells because they do not
> have the blank line after the indent.  Then I realized, aha, this is
> precisely what the notebook excels at: building up a code example with
> multi-line input in chunks.

Yes, that's really one thing it's great at.  And by purposefully
controlling explicit references to your axes, you can do the buildup
incrementally.  And the '>' "play" button in the new UI is great for
demos, as you can by and large run a demo just by clicking repeatedly
on that button.  I've been quite happy with that pattern.

Cheers,

f
_______________________________________________
IPython-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-user

[John Hunter-4]

On Thu, Feb 23, 2012 at 6:18 PM, Fernando Perez <[hidden email]> wrote:

Ahh, I can breathe better already :)  Speaking of the gallery (this is
getting OT for ipython), I think it's in serious need of a cleanup.  I
appreciate today's PR on organizing it by sections, but the real issue
is that over the years, the gallery has accrued a lot of scripts
without any comments or explanations of purpose, deprecated APIs, etc.
 I wonder if you could spur a 'gallery cleanup' project, encouraging
users to submit pull requests that remove duplicate/similar examples,
document better the ones left, etc.  While there's a lot of good stuff
there and I continue to point people to it, there really is also a
massive amount of weed growth that is starting to be annoying in
practice.

But the cleanup job is easy, can be done by non-experts (and is hence
a great one for new developers to start contributing) and would be
very beneficial to the project at large.

I will get involved in that thread.  I agree that something more curated would be preferable.  I'm imagining some sort of metadata one could drop in an example file.  eg, at the end of a *.py code example we could have some simple markup like (not wed to the format, just illustrating)::

  # _gallery_ 

  # topics: histograms, colormaps

  # rst: See :func:`~matplotlib.pyplot.hist` and :ref:`transforms_tutorial` for more info

  

and then the build process could drop it in a relevant section (or two) for the gallery.  Although the format is open to discussion, as the mockup illustrates we could support some additional rst style meta linkage to other docs, eg so the image/code pages could contain links to the api or other docs that the example illustrates.  Anything that is curated (and presumably we would comment and clean these as we tag them) would show up at the top of the gallery in the appropriate section, and we would have everything at the end in 'the weeds" so all the examples make it on to the page, but the stuff at the top is organized and clean.  We could support a section of example markup that is full blown sphinx/rest, so for each page that is already image + code, we could optionally have a section that is full-blown-rest that describes the example with relevant links to the rest of the docs. This would give us not only curated sections, as Ben's pull request already does, but lots of useful metadata on top.

I do believe it is important that even non-curated examples show up "in the weeds" since curating is not something we can count on and there is value in the gallery as it is showing *everything* even if it has not been blessed.  But if we can fix what the typical user sees *first*, and then show everything else after that, it will be an improvement.

I'll work with Ben on some of these ideas and maybe I can sprint on this at pydata with Ben remotely and any locals who are interested.

JDH

_______________________________________________
IPython-User mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/ipython-user