Re: A kernel, multiple notebooks, and Global?
- To: mathgroup at smc.vnet.net
- Subject: [mg87916] Re: A kernel, multiple notebooks, and Global?
- From: Bill Rowe <readnews at sbcglobal.net>
- Date: Sat, 19 Apr 2008 23:52:31 -0400 (EDT)
On 4/19/08 at 3:35 AM, siegman at stanford.edu (AES) wrote:
>>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
>Nope. If I need (more accurately, "want to re-use some part") of
>notebooks a or c from project A in project B, I just copy 'em over
>to the Project B folder! (Rule #N -- Disk space is cheap!).
>And once there, I can modify them for project B -- without screwing
>up the copies left back in the project A folder.
I agree with your observations here. And in an ideal world that
is all there is to it. But in the real world, I find every now
and then one or more of the functions I've created and copied to
various notebooks needs improvement. Perhaps, I didn't think of
a special case when I wrote the original code. Or perhaps, I've
found a more efficient algorithm. Or any number of other reasons
could make it desirable to alter the original code.
But now that the code is in several notebooks, it is difficult
to remember which notebooks need revision. Also, if one or more
have been modified in some way, a revision to one will not
necessarily be the same as needed for another notebook. And
finally, getting back to your original thoughts about having
several notebooks open at once, there is the problem of which
version of the function is active at any given time.
The solution to these issues is to encapsulate the functions
into a package so that each of the notebooks calls the same
code. But of course this gets back to writing packages,
something you seem to be trying to avoid.
>>In the time it took you to devise your own system, you could have
>>learned the standard package system. It is really not that
>Sorry -- can't agree. There are not a lot of complex steps involved
>in defining or using packages, agreed. **But digging the exact
>correct steps out of the documentation, learning the vocabulary,
>avoiding missteps, and remembering these steps after a time lag, are
>all frustrating and time-consuming**.
Yes, it is time consuming and can be frustrating as can be the
case with any learning. But there is payoff.
Prev by Date:
Next by Date:
Re: axis alignment of 3D plots with ListContourPlot3D
Previous by thread:
Re: Re: A kernel, multiple notebooks, and Global?
Next by thread: