Chapter 4
Dynamics, Manipulate, animations and related

4.1 Making animated GIF of a manipulate

One way is to use Vitaliy Kaurov ManToGif. Another way is to run the manipulate and do screen capture using program such as LICEcap

4.2 Guidelines for writing demonstration

In math italicize single Roman letters that are variables or 
functions  (example, x,y,f(x),t 
2. Exception to above is capital letters for points like P and Q in 
geometry. 
3. Do not italicize Greek letters (example, alpha, gamma, beta, etc..), 
   and units like sec or rad, or  punctuation like ( ). 
4. Styling the control labels is optional. 
5. Do not use strings with <> for such formatting. Use Row[{ăăă }] 
6. put () around units in plot labels. As (sec) or (hz) 
7. do not italicize function names longer than one letter. So Style["exp",Italic] 
   should just be "exp" 
8. The t in delta(t) should be italic--but not the delta, Greek letter are not 
   Italian letters is how I remember that. 
9. Log should be log. 
10. Is j^2= -1? Better say so in the caption for non EE.
 

see also http://demonstrations.wolfram.com/guidelines.html

I made small copy here so I do not have to keep looking for this all the time.

To put label on plot, example

To typeset math for display on the demo use this type of coding

Text@Style[TraditionalForm[HoldForm[Sin[x] + Cos[y]], 12]]
 

To add invisible space use ESC is ESC

4.3 Notes on dynamics

Useful notes taken from different places from Mathematica documentation. And some added by me.

1. (added 7/5/14) There is a race condition between when updating a variable in the second argument of dynamics, which is also updated in the Manipulate expression. The problem is easy to explain

   Manipulate[.... n=n+1;...., Manipulator[Dynamic[f,{f=#;n=0}&....]

   Now, what happens, sometimes, is that when moving the slider, and setting \(n=0\), that this update to \(n\) can be lost, since it depends on the timing of when this happens. The Manipulate expression could be in the middle on updating \(n\) itself. This is classical lost update problem in multi-threading. The way to avoid this, is to follow this rule of thumb: When using second argument of dynamics in a Manipulate control, do not update a shared variable which can also be updated inside the Manipulate expression, as the update can be lost. The write to the shared variable/updating should only happen either inside the Manipulate expression or in the second argument of dynamics. But not in both places

2. Dynamic is wrapped around the whole expression, so evaluation of the Table command is delayed until the output is displayed in the notebook. Any time the value of x is changed, the Table command will be reevaluated.
3. Remember that Dynamic has the effect of delaying evaluation until the expression reaches the front end
4. Because it has the attribute HoldFirst, Dynamic does not evaluate its first argument. This is fundamental to the workings of Dynamic, but it can lead to a somewhat unexpected behavior
5. Ordinary variables in Mathematica are owned by the kernel. Their values reside in the kernel, and when you ask Mathematica to display the value in the front end, a transaction is initiated with the kernel to retrieve the value.
6. Variables declared with DynamicModule, on the other hand, are owned by the front end. Their values reside in the front end, and when the front end needs a value, it can be retrieved locally with very little overhead.
7. The most important is the fact that values of all DynamicModule variables are saved in the file when the notebook is saved.
8. By default, dynamic outputs triggered by changes in variable values are updated no faster than twenty times per second (this rate can be changed with the SystemOption  "DynamicUpdateInterval").
9. Dynamic outputs are only updated when they are visible on screen.
10. Remember to add synchorization->False to all dynamics, else will time out. When using Refresh also.
11. Never make a refresh[] tracks on 2 of my own symbols (not control variables). Use tick, only. Causes major synchronization problems with I update 2 variables inside a refresh, and have the refresh tracks both. Only make one track local variable, such as ticks
12. Ok, Found out that finishDynamic[] can causes annoying refresh on the UI whenever I move sliders. So removed it.
13. Remember to use :> and not -> for TrackedSymbols

4.4 Notes from John Fultz collected on dynamics

Module variables should *never* appear inside Dynamics or 
Manipulates internal to that Module. 
 
To be clear with some examples (all using Dynamic, but they could equally well 
use Manipulate, which is implemented using Dynamic)... 
 
(* OK *) Dynamic[Module[{a}, a]] 
(* OK *) Module[{a}, 
                (* expression involving a*); 
                Dynamic[(* expression *not* involving a *)] 
(* BAD *) Module[{a}, Dynamic[a]]
 

By John Fultz on math group, jan 24/2012

"Generally, you should construct controls so that they’re not inside Dynamics that will trigger while you’re interacting with those controls, since this can create instability"

By John Fultz on math group, feb 3/2012

"CDF files which you expect to deploy cannot rely on Shift+Enter evaluations to prime the pump. You need to make sure that all of the code dependencies are in the dynamic evaluations somewhere. Some possible ways of doing this, all of which have been discussed at various points on MathGroup, include:

* Using the Initialization option of Dynamic, DynamicModule, or Manipulate

* Using the SaveDefinitions option of Manipulate

* Adding code to the NotebookDynamicExpression option of the notebook (if it’s initialization code, then wrapped in Refresh[#,None]& to prevent it from evaluating more than once per session).

* Not such a good idea for function definitions, but if you simply have code that needs to run before Dynamic code runs, nesting a DynamicWrapper around it might be appropriate, too."

4.5 Notes from WRI tech support on Dynamics and Manipulate

This is the support explanation of why this error came showed up: 
 
The issue is specifically with the section: 
Evaluate@env[{{age, 100, "age"}, 10, 200, 1}] 
 
Manipulate doesn't really evaluate until it gets to the Initialization 
option, but it will check its input for correct form. Mathematica 
reads the main body of the Manipulate before running the 
Initialization option. This is can be verified by using a Print statement: 
 
Initialization -> (Print["Test"]; 
  makeCustomEnvironmentAlt = 
   Function[Null, Function[code, With @@ Hold[{##}, code], HoldAll], 
    HoldAll]; 
  env = makeCustomEnvironmentAlt[$age = 1, $salary = 2]; 
  Print["Test"]) 
 
Test does not print. 
 
Getting around this will be probably not be clean. 
.... 
Having  the code for the controller for age depend on evaluation of 
some function which must be initialized does not appear to be possible 
with simply Manipulate.
 

see how-to-define-constants-for-use-with-with-in-one-place-and-then-apply-them-lat

4.6 Some useful posts and links on dynamics

why-wont-this-work-dynamic-in-a-select

When DynamicModule is first evaluated, initial assignments for local variables are made during the evaluation. Any setting for the Initialization option is evaluated only when the output of DynamicModule is displayed.

see how-to-make-dynamicmodule-work-without-an-extra-enter

Here is a trick to allow one to control one slider based on another

Manipulate[{a, b}, 
 Grid[{ 
 
   {"a", Manipulator[Dynamic[a, {(a = #) &, (a = #; If[b > a, b = a]) &}], 
          {1, 10, 1}], Dynamic[a]}, 
 
   {"b", Manipulator[Dynamic[b, {(b = #) &, (b = #; If[b > a, b = a]) &}], 
          {1, 10, 1}], Dynamic[b]}} 
  ], 
 
 {{a, 5}, None}, 
 {{b, 3}, None} 
 
 ]
 

4.7 Dynamically change the layout of Manipulate

Manipulate[x, 
 
 {x, {True, False}}, 
 Grid[{ 
   {Dynamic@If[x, 
      Control[{y, {True, False}}], 
      Control[{z, 0, 1, .1}] 
      ] 
    } 
   } 
  ] 
 ]
 

4.8 Compare Manipulate to DynamicModule

See convert_manipulate_to_dynamicModule

4.9 Usages of Manipulate

I wrote these for an answer here http://community.wolfram.com/groups/-/m/t/153862?p_p_auth=GLyok3xN

The manipulate expression is anything between the start of Manipulate and the first ","

Manipulate[Plot[Sin[x (1 + a x)], {x, 0, 6}], {a, 0, 2}]
 

It has the form

Manipulate[expression, controlVariables, Initialization :> ()]
 

4.9.1 case 1

foo[] := Plot[Sin[x (1 + a x)], {x, 0, 6}] 
Manipulate[Evaluate@foo[], {a, 0, 2}]
 

4.9.2 case 2

move foo[] in the above example to inside Manipulate, in the initialization section, add literal symbol a so Manipulate will track it

Manipulate[a; 
 foo[], {a, 0, 2}, 
Initialization :> 
 (foo[] := Plot[Sin[x (1 + a x)], {x, 0, 6}]) 
]
 

Notice the trick above. a was added so that it appears in the Manipulate expression. Otherwise, it will not be tracked. You’ll get an initial plot, but nothing will happen when moving the slider

4.9.3 case 3

move foo[] to global context, but have to tell Manipulate that LocalizeVariable is false

foo[] := Plot[Sin[x (1 + a x)], {x, 0, 6}]; 
Manipulate[a; 
 foo[], {a, 0, 2}, LocalizeVariables -> False]
 

But notice, we still need to put a somewhere in the expression for it to tracked. Not enough just to say LocalizeVariables -> False

4.9.4 case 4

It is not enough to use TrackedSymbols :>a, if the symbol itself do not show up in the expression. Hence this does not work

foo[] := Plot[Sin[x (1 + a x)], {x, 0, 6}]; 
Manipulate[foo[], {a, 0, 2}, LocalizeVariables -> False, TrackedSymbols :> a]
 

Notice there is no a in the expression. Manipulate will not track a even though we told it to !

4.9.5 case 5

Same as case 4, even if we put the function inside the Initialization section, it will still not track a . One will get an initial plot, but that is all.

Manipulate[foo[], {a, 0, 2}, 
  TrackedSymbols :> a, 
  Initialization :> 
   (foo[] := Plot[Sin[x (1 + a x)], {x, 0, 6}];)]
 

4.9.6 case 6

Putting the function definition of foo[] itself inside Manipulate expression, now Manipulate sees a there and will automatically track it. No need to do anything more:

Manipulate[Module[{}, foo[] := Plot[Sin[x (1 + a x)], {x, 0, 6}]; 
  foo[]], {a, 0, 2}]
 

Or simply

Manipulate[Plot[Sin[x (1 + a x)], {x, 0, 6}], {a, 0, 2}]
 

4.9.7 case 7

This is the method I use myself. Put all the functions inside the initialization section, but pass the dependent variables by argument call.

 
Manipulate[foo[a], {a, 0, 2}, 
  Initialization :> ( 
    foo[a_] := Module[{x}, Plot[Sin[x (1 + a x)], {x, 0, 6}]] 
)]
 

I like this, becuase it achieves both the goal of having all the slider symbols inside the Manipulate expression, hence Manipulate will track them, and at the same time, it avoid the function be in global context, and it is the modular way, since one can see which parameter each function depends on by looking at the signature of the function.

4.9.8 case 8

Similar to case 7, but the function itself is now in the global context. This is a fine solution as well, if this function needs to be called from somewhere else as well other than from the Manipulate. Otherwise, it is best not to have in the global context and use case 7.

foo[a_] := Module[{x}, Plot[Sin[x (1 + a x)], {x, 0, 6}]]; 
Manipulate[foo[a], {a, 0, 2}]
 

4.10 How to run CDF in Chrome browser?

Note: This is now (2024) no longer works. Can not run CDF any more in browsers.

Type this in the chrome window

chrome://flags/#enable-npapi

and click enable to enable NPAPI. Chrome now disables NPAPI and so CDF no longer runs inside browser. After doing the above, restart the browser again. Now it should run