[Date Index]
[Thread Index]
[Author Index]
Re: SelectionMove[nb,Next,?Group?]
*To*: mathgroup at smc.vnet.net
*Subject*: [mg112296] Re: SelectionMove[nb,Next,?Group?]
*From*: "David Park" <djmpark at comcast.net>
*Date*: Wed, 8 Sep 2010 00:58:41 -0400 (EDT)
Jeremy,
>From the tenor of your three questions it seems clear that you are
interested in using Mathematica to both develop technical material and
present it in a semi-classical style, while taking advantage of the active
dynamics of Mathematica.
The normal Mathematica working paradigm is Input/Output cells in a
Mathematica notebook. However, this is not the paradigm for classical
technical papers. Quite often the "input" part will be "boiler plate"
specification that you may not be interested in showing to the reader,
especially if it involves custom graphics, tables or dynamics. Sectional
grouping is very useful in writing notebook documents but they are not
especially useful for what you are suggesting. Input/Output cells can be
closed so you only see the Output portion, but as soon as you delete the
Output, the Input shows again. You can also permanently close an Input cell
so it only shows as a thin blank cell, but the reader may have difficulty
finding it if you want him to evaluate it.
The Presentations package has routines that help with a different approach.
It has a kind of MaTeX language for formatting up "page" displays. These can
contain two column displays that have comments on one side and mathematical
output on the other side. The mathematical output can have tooltips that
show the underlying Mathematica statements that produced the output.
Displays can be generated by buttons that are either standalone in a cell,
or are melded into a Text cell. Extended derivations, calculations or proofs
can be displayed as an organized collection of buttons that allow you to
click through the pages of the derivation. The buttons are bi-functional so
as to either display the page in the notebook, or launch the display in a
separate window. For example, one page might contain axioms and identities
used in a derivation so a reader could keep it up while going through the
other pages. This is a good way to present an extended derivation as a
connected unit and in a relatively compact space.
The specifications for the pages would be in separate sections, either at
the end of the notebook, or in subsections at the bottom of a section that
used them. I usually put the headings for these specification sections in
light gray to indicate that they could be ignored. Writing nice displays for
a notebook is a bit of work, because you do have to specify all of the
details. But if you have a nice piece of work, why not show it off?
There is a two-part video done by Roger Williams illustrating these
techniques (especially in the second video).
http://www.youtube.com/watch?v=-b0B5hp0hAQ
http://www.youtube.com/watch?v=Pm6yrevYcjQ
The best way to get a reasonable looking notebook is to roll your own style
sheet. You can choice the fonts, font sizes and other characteristics for
various types of cells. The things I like to see in a style sheet are:
1) Not too much variation in font size. Titles should not be too large and
Text should not be too small.
2) Output cells should basically look like Text cells with similar font size
and not have any adornment. So if you don't show Input cells the text and
output would meld together.
3) The sectional groupings should have openers, but nothing else should.
The package technology seems to suffer creep from version to version and so
it becomes difficult to say what is the best way to do it. The Notebook and
Cell Contexts were a good idea for documentation because a user could
evaluate examples in the documentation pages and never have to worry about
interfering with the user's notebook. However, if you are doing DC Paclet
documentation for a package, or an application with multiple packages, or
worse yet a package that uses the DeclarePackage mechanism, this all became
very problematical. It became necessary to load the package for every
example section or group, or specifically load sub-packages. So in Workbench
2.0 they seem to have gone back to the Global context, at least for
developers.
Nevertheless, I would like to say that Mathematica with packages and
Workbench is a wonderful way to write extended applications such as books,
research projects, college course material or study projects. Encapsulating
your developed routines in packages, documenting them, collecting finished
notebooks together, and linking it all together is a good way to develop and
preserve your work.
David Park
djmpark at comcast.net
http://home.comcast.net/~djmpark/
From: apjs64 [mailto:apjs64 at gmail.com]
I like the way mathematica uses groups and cells. In particular, I
would like to write code in a number of cells, encase in a group and
then close the group. When evaluation takes place I would like the
code group to remain closed and the output to be inserted between one
code group and the next. I have tried various combinations of
SelectionMove (including the optimistic
SelectionMove[nb, Next, Group]) but have not found a solution. Any
ideas?
thanks,
Jeremy
Prev by Date:
**Re: How to delay action of ...[[i]] (Part[...,i])**
Next by Date:
**Re: locating overlow/underflow (and the issue of accuracy)**
Previous by thread:
**SelectionMove[nb,Next,?Group?]**
Next by thread:
**What is the problem? There are no images and no wrong reports for this small program.**
| |