<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 4, 2014 at 9:01 AM, Jacob Biesinger <span dir="ltr"><<a href="mailto:jake.biesinger@gmail.com" target="_blank">jake.biesinger@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">What if we had a way to specify "report parameters", global variables you can modify using a widget interface (dropdown, slider, input box, etc but tied to multiple cells or possibly the whole notebook) and a caching mechanism to store notebook contents for each combination of report parameters? I'm imagining quickly switching the dataset for a series of graphs I'm looking at and having the graphs already cached for the ones I've looked at, or having the report run for any new combinations.</blockquote>

</div><br>Paul Ivanov might chime in soon, he and I discussed this a while back and I think he might even have some prototype code that could be a useful starting point.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

This is both a really important problem, and one that I think a lot of progress can be made on before we need to think about changes in IPython itself.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The direction Paul and I were considering was to annotate a cell with metadata indicating that it contains parameters, and then have something like runipy create new copies of the notebook varying each parameter over the specified range.  I actually think it's better, for now, to explicitly create copies of all notebooks, so it's a little easier to simply open one and look at it. I would have the tool simply dump the 'children' notebooks with names that make them all easy to later remove/clean up. But that makes it possible to simply open any one of them and inspect it, re-execute it manually with further tweaks, etc.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">And, it's the simplest thing that can possibly work, before thinking too hard about building new GUIs or anything else. All you need is:</div><div class="gmail_extra">

<br></div><div class="gmail_extra">- a note in the cell metadata.</div><div class="gmail_extra">- some markup syntax to specify in the cell the parameter ranges you want.</div><div class="gmail_extra">- a wrapper script that uses something like runipy and loops over the lot.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">That's what I'd do *first*, until I understood the use cases and problems better...  And the nice thing is that you can do all that today, without needing anything new whatsoever from upstream or having to mess with the code in IPython itself.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">f<br><br clear="all"><div><br></div>-- <br>Fernando Perez (@fperez_org; <a href="http://fperez.org" target="_blank">http://fperez.org</a>)<br>

fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)<br>fernando.perez-at-berkeley: contact me here for any direct mail<br>
</div></div>