MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: A kernel, multiple notebooks, and Global?

  • To: mathgroup at
  • Subject: [mg87785] Re: A kernel, multiple notebooks, and Global?
  • From: AES <siegman at>
  • Date: Wed, 16 Apr 2008 22:33:37 -0400 (EDT)
  • Organization: Stanford University
  • References: <fu1u15$ojn$> <fu21b9$rap$> <fu4fc7$nak$>

In article <fu4fc7$nak$1 at>, Albert Retey <awnl at> 

> 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.

  • Prev by Date: RE: Coordinates of vertices
  • Next by Date: Re: Re: Mathematica Player Pro!
  • Previous by thread: Re: A kernel, multiple notebooks, and Global?
  • Next by thread: Re: A kernel, multiple notebooks, and Global?