SaveDefinitions
is a nice option of Manipulate
. It causes Manipulate
to store any definitions used for its creation inside the Manipulate panel. A Manipulate made this way can be copied to an empty notebook and will still work on its own. Additionally, your working notebook containing many such Manipulates also doesn't turn into a flurry of pink boxes with printed error messages below it upon opening. Great!
However, all this goodness has its dark side which can bite you real hard if you are not aware of it. I've had this in a notebook I had been working on for a few days, but I present you with a step-by-step toy example scenario which recreates the problem.
In this scenario you want to create a Manipulate
showing a plot of a nice wavy function, so you define this (please make a window size like this, this is important):
The definition is nice, so we keep it for the next time and make it an initialization cell. Next we add the Manipulate
, and execute it too.
f[x_] := x^2
Manipulate[
Plot[n f[x], {x, -3, 3}],
{n, 1, 4},
SaveDefinitions -> True
]
All works great, the Manipulate really shines, it is a good day.
Just being your paranoid self you check whether the definition is OK:
Yeah, everything still checks out. Fine. But now it occurs to you that a better wavy function would be a sine, so you change the definition, execute, and being paranoid, check:
Everything still fine. You're ready from a day's hard work you save your work and quit. [Quit kernel]
Next day. You start your work again. You evaluate the initialization cells in your notebook. Definition still good? Check.
Now, you scroll down to your Manipulate box (no need to re-execute thanks to the SaveDefinitions
), play a little with the slider. And scroll back up.
Being the paranoid you, you once more check the definition of f:
Lo and behold, someone has changed the definition behind your back! And nothing executed between your first and second Information
(?) check according to the In[] numbers (In[1]
: def of f, In[2]
first ?, In[3]
second ?).
What happened? Well, it's the Manipulate
of course. A FullForm
reveals its internal structure:
Manipulate[Plot[n*f[x],{x, -3, 3}],{{n, 2.44}, 1, 4},Initialization:>{f[x_] := x^2}]
There you have the culprit. The initialization part of the box defines f again, but it's the old version because we didn't re-evaluate the Manipulate
after modifying its definition. As soon as the manipulate box gets on the screen, it is evaluated and you've got your old definition back. Globally!
Of course, in this toy example it is immediately clear something strange is happening. In my case, I had a larger module in a larger notebook in which I, after some debugging, had changed a small part. It seemed to work, but the next day, the same bug that had bugged me before hit again. It took me a couple of hours before I realized that one of the several Manipulates that I used to study the problem at hand from all sides was doing this.
Clearly, I'm tempted to say, this is unwanted behavior. Now, for the obligatory question: what can we do to prevent this behind-your-back behavior of Manipulate
from occurring other than re-executing every Manipulate
in your notebook each time you change a definition that might be used by them?
The answer is to use initialization cell as initialization for the
Manipulate
:You can also use
DynamicModule
:You do not need
SaveDefinitions -> True
in this case.EDIT
In response to Sjoerd's comment. With the following simple technique you do not need to copy the definition everywhere and update all copies if you change the definition (but you still need to re-evaluate your code to get updated
Manipulate
):Here is an attempt. The idea is to identify symbols with
DownValues
or some other...Values
inside your manipulated code, and automatically rename them using unique variables / symbols in place of them. The idea here can be executed rather elegantly with the help of cloning symbols functionality, which I find useful from time to time. The functionclone
below will clone a given symbol, producing a symbol with the same global definitions:There are several alternatives of how to implement the function itself. One is to introduce the function with another name, taking the same arguments as
Manipulate
, saymyManipulate
. I will use another one: softly overloadManipulate
viaUpValues
of some custom wrapper, that I will introduce. I will call itCloneSymbols
. Here is the code:Here is an example of use:
Note that to use the new functionality, one has to wrap the
SaveDefinitions->True
option inCloneSymbols
wrapper:This will not affect the definitions of original symbols in the code inside
Manipulate
, since it were their clones whose definitions have been saved and used in initialization now. We can look at theFullForm
for thisManipulate
to confirm that:In particular, you can change the definitions of functions to say
Then move the slider of the
Manipulate
produced above, and then check the function definitionsThis
Manipulate
is reasonably independent of anything and can be copied and pasted safely. What happens here is the following: we first find all symbols with non-trivialDownValues
,SubValues
orUpValues
(one can probably addOwnValues
as well), and useCases
andclone
to create their clones on the fly. We then replace lexically all the cloned symbols with their clones insideManipulate
, and then letManipulate
save the definitions for the clones. In this way, we make a "snapshot" of the functions involved, but do not affect the original functions in any way.The uniqueness of the clones (symbols) has been addressed with the
unique
function. Note however, that while theManipulate
-s obtained in this way do not threaten the original function definitions, they will generally still depend on them, so one can not consider them totally independent of anything. One would have to walk down the dependency tree and clone all symbols there, and then reconstruct their inter-dependencies, to construct a fully standalone "snapshot" in Manipulate. This is doable but more complicated.EDIT
Per request of @Sjoerd, I add code for a case when we do want our
Manipulate
-s to update to the function's changes, but do not want them to actively interfere and change any global definitions. I suggest a variant of a "pointer" technique: we will again replace function names with new symbols, but, rather than cloning those new symbols after our functions, we will use theManipulate
'sInitialization
option to simply make those symbols "pointers" to our functions, for example likeInitialization:>{new1:=f,new2:=g}
. Clearly, re-evaluation of such initialization code can not harm the definitions off
org
, and at the same time ourManipulate
-s will become responsive to changes in those definitions.The first thought is that we could just simply replace function names by new symbols and let
Manipulate
initialization automatically do the rest. Unfortunately, in that process, it walks the dependency tree, and therefore, the definitions for our functions would also be included - which is what we try to avoid. So, instead, we will explicitly construct theInitialize
option. Here is the code:With the same definitions as before:
Here is a
FullForm
of producedManipulate
:The newly generated symbols serve as "pointers" to our functions. The
Manipulate
-s constructed with this approach, will be responsive for updates in our functions, and at the same time harmless for the main functions' definitions. The price to pay is that they are not self-contained and will not display correctly if the main functions are undefined. So, one can use eitherCloneSymbols
wrapper orSavePointers
, depending on what is needed.