[IPython-dev] Re: notebook composition UI thoughts
Robert Kern
rkern at ucsd.edu
Fri Jul 8 19:32:52 EDT 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