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 >>Mathematica system. >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 >>difficult. >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.