Re: A kernel, multiple notebooks, and Global?
- To: mathgroup at smc.vnet.net
- Subject: [mg87824] Re: A kernel, multiple notebooks, and Global?
- From: "David Park" <djmpark at comcast.net>
- Date: Fri, 18 Apr 2008 02:38:45 -0400 (EDT)
- References: <fu1u15$ojn$1@smc.vnet.net> <fu21b9$rap$1@smc.vnet.net> <fu4fc7$nak$1@smc.vnet.net> <fu6mhj$nni$1@smc.vnet.net>
AES, I would like to put in a pitch for using the standard Mathematica package method and maybe even go further and learn something about documentation. I think one of the unstated assumptions here is that no one else is going to see your Mathematica work because all of the pertinent results will be Exported or copied out into non-Mathematica documents before being transmitted to a larger public. In that case why not organize the internal work in the way that seems most convenient to you? But another assumption that we can make for certain is that you have expert knowledge and a lot of experience in optical fibers. You also have done, and will do a lot of work in organizing the theory and calculation methods for the field. This is valuable stuff! So why not make it available to others in the Mathematica format with all of its advantages of dynamics and interactivity. In addition to the final results, if you have worked out various algorithms, calculation and display routines these are valuable. Why not make them available to other people as Mathematica packages? If you follow the multiple notebook paradigm, you also have to devise some kind of organization for the notebooks. You have to remember that for WorkingNotebookA you need ModuleNotebooks a, c and f. But for WorkingNotebookB you need ModuleNotebooks a, b, and c. Pretty soon you are designing your own system, which is not the standard Mathematica system. People who might use your notebooks not only have to learn the standard system (because they might be doing other things as well) but they also have to learn your special system. Rule Number 1: WRI has put a lot of thought into designing a user interface. It work's fairly well. Be very wary of interposing your own interface. In the time it took you to devise your own system, you could have learned the standard package system. It is really not that difficult. A Mathematica package is just a simple particular form of notebook with Initialization cells. You just save it as an Auto Generated Package and that is all there is to it. If you organize your notebooks using Sections (and I wonder if using multiple notebooks is a substitute for using Sectional organization within a notebook?), then you can initially put your routines in a Routines Section. The notebook does not have to be 'visually large' because the Routines Section can usually be closed up. Other things should also be in Sections. (When I'm working on a particular derivation of development I put it in its own Section. If I don't especially like it or get stuck I usually mark it as Try 1, close it up, copy and paste it and work on a Try 2. When I finally get something I like I throw all the false steps away.) When you develop a routine in a working notebook, move it to the Routines Section and write a usage message for it and make it an Initialization cell. If you start a new working notebook, copy the Routines Section over. At some point, you will be convinced that some of the routines are in good shape for general use. Then move them to your OpticalFiber package. Then you will have one simple working structure. A single package and working notebooks that load the package. You or your readers don't have to look at any of the package code anymore. You may still have some things in your Routines Sections that haven't yet made it to the package. Documentation is another question, but again, if you have worked out good routines and methods they are really worth something to other people and deserve to be documented. (And in any case, I find that I am always forgetting how some of my own routines work and have to refer to my own documentation!) With a little cleverness the documentation can also serve as a set of test cases if you make changes to your routine. Working on documentation also helps to perfect a routine. Sometimes if it is difficult to explain and illustrate a routine one might wonder about it basic design. It's true that this takes time, but it's a focused and productive use of one's time. David Reiss has put up a good introduction to creating Version 6 documentation. http://www.scientificarts.com/worklife/notebooks/ and the Workbench application for documentation is coming along. Rule Number 2: Most users of Mathematica are pretty capable people. Turn your hard work into permanently useful and active knowledge for yourself and other people. -- David Park djmpark at comcast.net http://home.comcast.net/~djmpark/ "AES" <siegman at stanford.edu> wrote in message news:fu6mhj$nni$1 at smc.vnet.net... > In article <fu4fc7$nak$1 at smc.vnet.net>, Albert Retey <awnl at arcor.net> > wrote: > >> I just wanted to mention this for the case that the OP asked this >> question because he is trying to track down a problem related to this. > > Thanks for this and other replies to this query -- which generally seem > to say that, unless you do something to deliberately manipulate > contexts, a group of several simultaneously open notebooks can generally > be used as if they were all parts of one big notebook with one overall > global context. > > I didn't raise this question because of any problems I've encountered, > but rather to flush out any problems that might arise in the "packages > without Packages" approach that I'd like to start implementing for my > particular Mathematica style of use (and it looks like there needn't be > any such problems). > > This approach says, in essence, that I'm often working on 3 or 4 > different physical problems, with the currently active projects changing > from time to time (and old projects reviving from time to time). > > So, I'd like to keep all the materials associated with any given > project -- notes, references, other memos, graphics and artwork, > materials for publications resulting from the project == and, > especially, all the Mathematica notebooks for that project -- in a > separate > master folder for that project. > > Moreover, I'd like to have all the Mathematica "accessories" -- like any > "packages" or modules that do some major computational or display tasks > for that project -- be right there, in that same subfolder with the > primary notebooks for the project. > > A typical project -- a study of optical fiber propagation, let's say -- > generally has a limited and consistent set or glossary of primary > parameters and variables, set by the physics of the problem and the > conventional notation in the field, and thus easy to remember. So, > those quantities might as well all be global variables, used with the > same meaning in all the project notebooks. > > Suppose then that we might at different times want to do calculations > and display results on the modes of these optical fibers, or on their > propagation characteristics, or their thermal behavior, or on a > perturbation aspect of their behavior, or whatever. > > Rather than have one large, unwieldy notebook to do all these tasks, we > might better have a number of separate much smaller task notebooks that > are appropriately named ("OpticalFiberModes.nb", etc) and that each do > one limited part of the overall project -- and then one "modules > notebook" ("OpticalFiberModules.nb") that contains various common basic > function and equation definitions for the project, plus individual > display modules that create certain graphics or tabular displays of > results, plus computational modules that do some complicated iterative > numerical calculations -- in other words, any stuff that's lengthy or > that might go into a Package in other circumstances. > > At a given time, one might have only one or two task notebooks open, > plus the "modules" notebook (no real problem on a modern computer > screen). If you're polishing up a certain graphic display routine, you > edit this routine (probably as a Module[]) in the modules notebook; > execute the modules notebook to refresh it (which is very fast, since > this notebook does nothing but definitions); then jump to and run the > task notebook that calls it, and back again if further editing is needed. > > What are the virtues of this approach? > > * Each task notebook can be comparatively short and free of long module > definitions -- and thus can be navigated through quickly. > > * The modules notebook may be longer -- but if too long can be split > into "setup modules", "display modules", "computational modules". > > * **You never have to learn how to create/edit/modify/store away > Packages! -- a great virtue, from what the questions I've seen > repeatedly posed in this group. > > * Maybe more important, you don't have to **remember** any of this > knowledge on how to work with Packages, nor do you have to remember how > you defined a Package, or how to use it, over possibly long interim > periods between active periods of a given project. All that knowledge > is right there at hand, in the modules notebook, if you go back later to > that project. > > * If you need one part of a project's modules notebook in another > project, you just copy it over into that project's modules notebook. > > I'm not attacking Packages here. It's just that they're necessarily > pretty sophisticated constructs (and have to be, if they're going to > function in the full Mathematica environment). Hence they have a > significant > learning curve (and a significant 'evaporation rate' if one moves away > from them for any period of time). The above approach seems like it may > work for me, and give me one fewer messy construct in Mathematica to > worry about. > > I don't see any serious downsides to this approach, although if any are > pointed out by readers -- if any -- of this lengthy screed, I'll > certainly have to learn from them. >