[IPython-dev] Some new cell types for describing data analyses in IPy. Notebook

[Gabriel Becker]

Stefan,

My biggest issue with this is that branching is not a cell-level phenomenon.

The example in my video/screenshots have branches that each only contain
one cell, but that was largely for simplicity and the ability to fit it all
on screen for illustration purposes.

In most cases a branch in the sense that I am envisioning them will
actually be a sequence of cells which together make up a particular
alternative (strategy|algorithm|implementation|*). They need to be tracked
as a group and operated on as a group. It is explicitly invalid (though not
prevented currently in my PoC) when given 2 branches with 3 cells each, to
run the first cell in branch one, then the second cell from branch 2, then
the third from branch one again. That doesn't constitute a valid path
through the document.

Having the branches stored externally (which is what putting them in git
amounts to) also seems like it would gut our ability to easily reason about
the structure of and navigate through the document. Under this model
navigating between paths through the analysis actually changes content of
the notebook itself. Also given four distinct sets of branches, how does
that translate into the actual document structure? Even attempting to do so
requires scraping data from the git repo, and its not clear how
straightforward things would be even in that case.

Nesting branches (alternative analysis strategies, one branch of which
contains alternative choices for model specification, for example) seem
tough to do as well in a way that we can easily extract and reason about
when we want to render or navigate the notebook.

~G



On Wed, Jul 10, 2013 at 11:40 AM, Stéfan van der Walt <stefan at sun.ac.za>wrote:

> On Wed, Jul 10, 2013 at 8:25 PM, Gabriel Becker <gmbecker at ucdavis.edu>
> wrote:
> >
> > That having been said, there is a far cry between git being the place
> that the devs think notebooks *should* live and not having notebooks in git
> being unsupported. I would argue building actual application features on
> git brings us pretty firmly into the latter category.
>
> The approach I suggested depends only on one IPython feature: per-cell
> meta-data.  I don't think that will go away any time soon.  The
> solution is bolted on top, so it does not rely on any support inside
> of IPython.  Also, you can then choose which configurations to run and
> generate your output.  In the end, you'll still have to compare the
> output somewhat manually (even though we can potentially track the
> outputs via version control too, making things easier).
>
> Stéfan
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Gabriel Becker
Graduate Student
Statistics Department
University of California, Davis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20130711/1475e249/attachment.html>