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