<div dir="ltr"><div>Matthias,<br><br></div>Thanks for your detailed response.<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 3, 2013 at 1:25 AM, Matthias BUSSONNIER <span dir="ltr"><<a href="mailto:bussonniermatthias@gmail.com" target="_blank">bussonniermatthias@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Gabriel, <div><br></div><div>You screen shot are interesting, </div>
<div>At some point I played with gridster[1]</div><div><br></div><div>and was more or less able to get cell to rearranges, but didn't keep the code. </div><div>You might be interested. </div><div><br></div><div><div>
Keep in mind that the notebook browser-interface we ship is only one possible</div>
<div>frontend that can interpret ipynb files, nothing prevent you to write a</div><div>different frontend that display the notebook in a different format. </div><div><br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="word-wrap:break-word"><div><div></div><div>This added to the fact that each cell can support arbitrary metadata, you</div><div>should be able to arrange preexisting in structure that work together. It might</div>
<div>be a little difficult to do it right now as our javascript is not yet modular</div><div>enough to be easily reused, but we are moving toward it.</div></div></div></blockquote><div><br></div><div>Respectfully, rolling my own frontend for ipynb files given all the work the IPython team has done on the excellent notebook browser interface would be an enormous and extremely wasteful duplication of effort. I don't think its the right way to pursue these features.<br>
<br>Furthermore, if I were going to write an application offering the types of features I am talking about from scratch, there wouldn't be any good reason to base it on the unaltered ipynb format, as they don't easily support the structure required by those features without the additional cell types I implemented in my forked version. <br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>Right now I thing storing the notebook as a directed graph is problematic in a</div>
<div>few way,</div></div></div></blockquote><div><br></div><div>I'm not talking about storing the notebook as an actual directed graph data structure. There would be benefits to that but its not necessary and it isn't want I did in my forked version.<br>
<br></div><div>The ability to have nested cells (cells which contain other cells) gets us everything we need structure wise, and is the basis of everything seen in both the video (other than interactive code cell stuff) and screenshots I posted. The ipynb file for the notebook pictured in the screenshot looks exactly like a normal ipynb file except that in the json there are cell declarations which have a cells field which contains the json descriptions of the cells contained in that cell.<br>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div> the first being that it is incompatible with the fact that people want</div>
<div>to be able to run notebook in a headless manner, which if you add explicit</div><div>choice is not possible. </div></div></div></blockquote><div><br></div><div>This isn't the case. The json saved versions of notebooks with branching remember which version was most recently run. When an altset cell is executed, it runs only the most recently run (or currently "selected", though that means something else internally) branch. Thus by doing the naive thing and looping through all top level cells and executing them, the currently chosen path through the notebook can easily be run in a headless environment and give the correct results.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>This also contradict the fact that the notebook capture</div>
<div>both the input and the output of the computation. </div></div></div></blockquote><div><br>I don't really understand what you mean by this. In the JSON
representation of an executed code cell, the input field contains the code, but
not any values of variables used by the code, nor any indication of code
which was run before executing the code cell.<br><br>Changing and rerunning an earlier code cell without re-executing the cell in question can easily invalidate the output stored in the JSON, even without the concept of branching or choice.<br>
<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>As you showed there is</div><div>actually 18 different combinations of data analysis, and they are not all</div>
<div>stored in the notebook. </div></div></div></blockquote><div><br></div><div>The notebook knows and records which choices were made. There are 18 different combinations of data analysis <i>but only one was chosen by analyst as generating the final/most recent result</i>. <br>
<br>In the case of "publishing" about an analysis the notebook stores the path most chosen by the analyst, while retaining information about what else he or she did during the decision process.<br></div><div><br>
</div><div>In the case of instruction, imagine how much easier it would be to teach data analysis if the students could actually see what data analysts do, instead of simply the final method they choose in a particular analysis.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div>I really thing this is an interesting project, and reusing only our metadata in</div>
<div>the notebook, you should be able to simulate it (store the dag in notebook</div><div>level metadata, and cell id in cell metadata) then reconstruct the graph when</div><div>needed. Keep in mind that at some point we might/will add cell id to the</div>
<div>notebook.</div><div><br></div><div>To sum up, I don't think the current JS client is in it's current state the</div><div>place to implement such an idea. The Dag for cell order might be an idea for</div><div>
future notebook format but need to be well thought, and wait for cell IDs.</div></div></div></blockquote><div><br></div><div>I apologize for not being clear. As I said in a response above, the directed graph idea was intended to be conceptual for thinking about the documents, not structural for actually storing them.<br>
<br></div><div>What I actually did was simply allow cell nesting and change indexing so that it is with respect to the parent/container (cell or notebook) instead of always with respect to the notebook. This required some machinery changes but not too many and it is an extension in the mathematical sense in that indexing will behave identically to the old system for notebooks without any nesting while now meaningfully functioning for notebooks with nesting.<br>
</div><div> <br></div><div>~G<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span><font color="#888888"><div>
<br></div></font></span></div><span><font color="#888888"><div>-- </div><div>Matthias</div><div><br></div><div><br></div><div><br></div><div>[1] <a href="http://gridster.net/" target="_blank">http://gridster.net/</a></div>
</font></span></div><br>_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org" target="_blank">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Gabriel Becker<br>Graduate Student<br>Statistics Department<br>University of California, Davis<br>
</div></div>