[IPython-dev] Widget idea: Global Parameters

Maximilian Albert maximilian.albert at gmail.com
Sun Apr 6 11:06:45 EDT 2014

Hi all,

somewhat complementary, but it might be useful to combine some of the
ideas mentioned here with tools like Sumatra [1], which might be
useful for further automization and/or reproducibility. I haven't
thought about this deeply, but offhand I could imagine that it would
help with some of the caching issues mentioned (because the outcome of
different simulation/analysis runs is stored in a database, so it
would be easy to get the data or plots corresponding to a specific
parameter set).


P.S.: If anyone knows of tools similar to Sumatra, I'd be interested
to hear about them (although it may be better to devote a separate
thread to this).

[1] http://pythonhosted.org/Sumatra/

2014-04-05 20:58 GMT-04:00 Fernando Perez <fperez.net at gmail.com>:
> On Fri, Apr 4, 2014 at 9:01 AM, Jacob Biesinger <jake.biesinger at gmail.com>
> wrote:
>> 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.
> 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.
> 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.
> 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.
> 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:
> - a note in the cell metadata.
> - some markup syntax to specify in the cell the parameter ranges you want.
> - a wrapper script that uses something like runipy and loops over the lot.
> 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.
> Cheers,
> f
> --
> Fernando Perez (@fperez_org; http://fperez.org)
> fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
> fernando.perez-at-berkeley: contact me here for any direct mail
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

More information about the IPython-dev mailing list