[IPython-dev] Re: notebook composition UI thoughts

Robert Kern rkern at ucsd.edu
Fri Jul 8 18:32:52 CDT 2005


Michael Tobis wrote:
> On 7/6/05, Robert Kern <rkern at ucsd.edu> wrote:
> 
>>The current document model has two separate sections: a log and a sheet.
>>The log contains all of the text from the In[NN] and Out[NN] prompts and
>>other information. Each element is tagged with the number NN. The sheet
>>contains the rich text that you write and references to those elements
>>in the log. The sheet can contain any, all, or none of the elements in
>>the log in any order and with any number of repetitions.
> 
> If I understand you correctly, then the plan does NOT adequately
> address my concerns with the Mathematica approach, concerns which I
> believe Hans acknowledged.
> 
> A second notebook with the same visible inputs in the same order as a
> first notebook should, in my opinion, be required to yield the same
> results in both cases.
 >
> If the sequence of operations is set in a log file normally invisible
> to the user, then, as in Mathematica, two notebooks can have the same
> sequence of inputs and different sequences of outputs.

Every input and output cell is visually marked with its number, just as 
in current ipython. The placement of the input cells in the document may 
not correlate with the order they would be reexecuted. The numbers will 
determine the order of execution. The same sequence of inputs (ordering 
  by the numbers) will give the same outputs. If I rearrange the 
position of the input cells in the document, the order of execution 
remains the same. Whether you actually do rearrange the positions, or 
visually remove cells, is up to you. As you say, "the order in which the 
reader wants to read the code does not necessarily match the order in 
which the compiler wants to process it." The order the interpreter wants 
to process the code is provided by the numbers of the input cells. The 
order the reader wants to read the code is given by the placement of 
those cells in the document.

There, of course, is the option of manually changing the numbers in 
order to exercise a finer control over how the document might be 
reexecuted. Additionally, we can enable more automatic renumberings as 
well. For example, suppose that I don't want any of the cells I visually 
removed from the document to show up in the log, and I want the cells 
renumbered to be contiguous (e.g. instead of skipping from 10 to 14 if I 
deleted cells 11, 12, and 13). We can provide a command that will clean 
the log and make the appropriate changes to the cells in the visual 
document.

> This will tend to frustrate and drive away a developer of serious
> content for the medium. Invisible statements and invisible or at least
> unemphasized changes in the sequence of operations will cause the
> notebook to fail to behave in the way that the content developer wants
> or naturally expects.

They are emphasized by the numbers attached to the cells. We can make an 
option (via a menu, keyboard shortcut, or toolbar button) that will 
display the full log.

>> When executed,
>>the notebook will only consider the elements in the log in order. The
>>formatting of the sheet is irrelevant to execution.
> 
> If I understand you correctly, then you are replacing Mathematica's
> inconsistency with a method that is simple, consistent, and wrong.

Quite possibly. However, it a method that is achievable. If you can 
contribute code that supports more complicated semantics, we will 
consider it.

I think, however, that I am not explaining myself quite clearly enough. 
I do believe that the approach I have described does address most of 
your concerns.

>>At the moment, we are focusing on creating an interactive environment,
>>not a code development environment. 
> 
> I find this distinction not especially helpful. I am using an editor
> to construct a document to tell a computer what to do. How is this not
> code development?

It's the difference between writing a module and typing at the ipython 
prompt. I, at least, approach these activities very differently.

> Sorry to be so strong about this, but I hate to see this unfortunate
> road traveled again.
> 
> Michael Tobis

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter




More information about the IPython-dev mailing list