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: <fu1u15$ojn$1@smc.vnet.net> <fu21b9$rap$1@smc.vnet.net> <fu4fc7$nak$1@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.