Re: A kernel, multiple notebooks, and Global?
- To: mathgroup at smc.vnet.net
- Subject: [mg87785] Re: A kernel, multiple notebooks, and Global?
- From: AES <siegman at stanford.edu>
- Date: Wed, 16 Apr 2008 22:33:37 -0400 (EDT)
- Organization: Stanford University
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com>
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.