Wolfram Mathematica® Tutorial Collection

DYNAMIC INTERACTIVITY
For use with Wolfram Mathematica® 7.0 and later.

For the latest updates and corrections to this manual:

visit reference.wolfram.com
For information on additional copies of this documentation:
visit the Customer Service website at www.wolfram.com/services/customerservice
or email Customer Service at info@wolfram.com
Comments on this manual are welcomed at:
comments@wolfram.com
Content authored by:
Theodore Gray and Lou D'Andria

Printed in the United States of America.

15 14 13 12 11 10 9 8 7 6 5 4 3 2

©2008 Wolfram Research, Inc.

All rights reserved. No part of this document may be reproduced or transmitted, in any form or by any means,
electronic, mechanical, photocopying, recording or otherwise, without the prior written permission of the copyright
holder.
Wolfram Research is the holder of the copyright to the Wolfram Mathematica software system ("Software") described
in this document, including without limitation such aspects of the system as its code, structure, sequence,
organization, “look and feel,” programming language, and compilation of command names. Use of the Software unless
pursuant to the terms of a license granted by Wolfram Research or as otherwise authorized by law is an infringement
of the copyright.
Wolfram Research, Inc. and Wolfram Media, Inc. ("Wolfram") make no representations, express,
statutory, or implied, with respect to the Software (or any aspect thereof), including, without limitation,
any implied warranties of merchantability, interoperability, or fitness for a particular purpose, all of
which are expressly disclaimed. Wolfram does not warrant that the functions of the Software will meet
your requirements or that the operation of the Software will be uninterrupted or error free. As such,
Wolfram does not recommend the use of the software described in this document for applications in
which errors or omissions could threaten life, injury or significant loss.
Mathematica, MathLink, and MathSource are registered trademarks of Wolfram Research, Inc. J/Link, MathLM,
.NET/Link, and webMathematica are trademarks of Wolfram Research, Inc. Windows is a registered trademark of
Microsoft Corporation in the United States and other countries. Macintosh is a registered trademark of Apple
Computer, Inc. All other trademarks used herein are the property of their respective owners. Mathematica is not
associated with Mathematica Policy Research, Inc.
Contents

Introduction to Dynamic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Advanced Dynamic Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Introduction to Manipulate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Advanced Manipulate Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Generalized Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Introduction to Dynamic
This tutorial describes the principles behind Dynamic, DynamicModule and related functions,
and goes into detail about how they interact with each other and with the rest of Mathematica.

These functions are the foundation of a higher-level function Manipulate that provides a simple
yet powerful way of creating a great many interactive examples, programs, and demonstra-
tions, all in a very convenient, though relatively rigid, structure. If that structure solves the
problem at hand, you need look no further than Manipulate and you do not need to read this
tutorial. However, do continue with this tutorial if you want to build a wider range of structures,
including complex user interfaces.

This is a hands-on tutorial. You are expected to evaluate all the input lines as you
reach them and watch what happens. The accompanying text will not make sense
without evaluating as you read.

The Fundamental Principle of Dynamic

Ordinary Mathematica sessions consist of a series of static inputs and outputs, which form a
record of calculations done in the order in which they were entered.

Evaluate each of these four input cells one after the other.
In[1]:= x = 5;

In[2]:= x2
Out[2]= 25

In[1]:= x = 7;

In[4]:= x2
Out[4]= 49

The first output still shows the value from when x was 5, even though it is now 7. This is, of
course, very useful, if you want to see a history of what you have been doing. However, you
may often want a fundamentally different kind of output, one that is automatically updated to
always reflect its current value. This new kind of output is provided by Dynamic.

Evaluate the following cell; note that the result will be 49 because the current value of x is 7.
 2 Dynamic Interactivity

Evaluate the following cell; note that the result will be 49 because the current value of x is 7.

In[5]:= DynamicAx2 E

In fact it is generally the case that when you first evaluate an input that contains variables
wrapped in Dynamic, you will get the same result as you would have without Dynamic. But if
you subsequently change the value of the variables, the displayed output will change
retroactively.

Evaluate the following cells one at a time, and note the change in the value displayed above.
In[6]:= x = 9;

In[7]:= x = 15;

In[8]:= x = 10;

The first two static outputs are still 25 and 49 respectively, but the single dynamic output now
displays 100, the square of the last value of x. (This sentence will, of course, become incorrect
as soon as the value of x is changed again.)

There are no restrictions on the kinds of values that can go into a dynamic output. Just because
x was initially a number does not mean it cannot become a formula or even a graphic in subse-
quent evaluations. This might seem like a simple feature, but it is the basis for a very powerful
set of interactive capabilities.

Each time the value of x is changed, the dynamic output above is updated automatically. (You
might need to scroll back to see it.)
1
In[9]:= x = IntegrateB , yF;
1 - y3
In[10]:= x = Plot@Sin@xD, 8x, 0, 2 Pi<D;

In[1]:= x = 0;

Dynamic@exprD an object that displays as the dynamically updated current

value of expr

Basic dynamic expression.

 Dynamic Interactivity 3

Dynamic and Controls

Dynamic is often used in connection with controls such as sliders and checkboxes. The full
range of controls available in Mathematica is discussed in "Control Objects"; here sliders are
used to illustrate how things work. The principles of using Dynamic with other controls is basi-
cally the same.

A slider is created by evaluating the Slider function, in which the first argument is the position
and the optional second argument specifies the range and step size, with the default range
from 0 to 1 and the default step size 0.

This is a slider in a centered position.

In[11]:= Slider@0.5D

Out[11]=

Click on the thumb and move it around. The thumb moves, but nothing else happens since the
slider is not connected to anything.

This associates the position of the slider with the current value of the variable x. (This form is
explained in more detail later.)
In[12]:= Slider@Dynamic@xDD

Out[13]=

This creates a new dynamic output of x since the last one has probably scrolled off your screen
by now.
In[14]:= Dynamic@xD
Out[14]= 0.

Drag the last slider around. As the slider moves, the value of x changes and the dynamic output
updates in real time.

The slider also responds to changes in the value of x.

To see this, evaluate this line.

In[15]:= x = 0.8;
 4 Dynamic Interactivity

You should see the slider jump, and the dynamic output of x change, simultaneously.

This creates another x slider.

In[16]:= Slider@Dynamic@xDD

Out[16]=

Notice that if you move either of the two sliders you now have, the other one moves in "lock
sync." Both are connected, dynamically and bi-directionally, to the current value of x.

Dynamic and Other Functions

Dynamic and control constructs such as Slider are in many ways just like any other functions
in Mathematica. They can occur anywhere in an output, in tables, and even inside typeset
mathematical expressions. Wherever these functions occur, they carry with them the behavior
of dynamically displaying or changing in real time the current value of the expression or vari-
able they are linked to. Dynamic is a simple building block, but the rest of Mathematica turns it
into a flexible tool for creating nimble, zippy, and often fun little interactive displays.

This makes a table of x sliders, which are updated in sync.

In[2]:= Table@Slider@Dynamic@xDD, 84<D

Out[2]= : , ,

, >

You can combine a slider with a display of its current value in a single output.
In[3]:= 8Slider@Dynamic@xDD, Dynamic@xD<

Out[3]= : , 0.>
 Dynamic Interactivity 5

The great power of Dynamic lies in the fact that it can display any function of x just as easily.
In[20]:= 8Slider@Dynamic@xDD, Dynamic@Plot@Sin@10 y xD, 8y, 0, 2 Pi<DD<
1.0

0.5

Out[20]= : , >
1 2 3 4 5 6

-0.5

-1.0

Using integer-valued sliders, you can create dynamically updated algebraic expressions.

In[21]:= 9Slider@Dynamic@x1D, 81, 10, 1<D, DynamicAExpandAHa + bLx1 EE=

Out[21]= : , a + b>

You can use dynamic expressions with Panel , Row, Column, Grid , and other formatting
constructs.
In[22]:= Panel@Column@8Row@8Slider@Dynamic@xDD, Dynamic@xD<D,
Dynamic@Plot@Sin@10 y xD, 8y, 0, 2 Pi<DD<DD

0.

1.0

0.5

Out[22]=
1 2 3 4 5 6

-0.5

-1.0

Notice that the last example resembles the output of Manipulate. This is no coincidence,
because Manipulate in fact produces a combination of Dynamic, controls, and formatting
constructs, not fundamentally different from what you can do yourself using these lower-level
functions.
 6 Dynamic Interactivity

Localizing Variables in Dynamic Output

Here is another copy of a slider connected to a simple plot.

In[23]:= 8Slider@Dynamic@xDD, Dynamic@Plot@Sin@10 y xD, 8y, 0, 2 Pi<DD<
1.0

0.5

Out[23]= : , >
1 2 3 4 5 6

-0.5

-1.0

This is a slider connected to another function.

In[24]:= 8Slider@Dynamic@xDD, Dynamic@Plot@Tan@10 y xD, 8y, 0, 2 Pi<DD<
1.0

0.5

Out[24]= : , >
1 2 3 4 5 6

-0.5

-1.0

If you have both these outputs visible and drag either slider, you will notice that they are com-
municating with each other. Move the slider in one example, and the other example moves too.
This is because you are using the global variable x in both examples. Although this can be very
useful in some situations, most of the time you would probably be happier if these two sliders
could be moved independently. The solution is a function called DynamicModule.

DynamicModule@8x,y,…<,exprD an object which maintains the same local instance of the

symbols x, y, … in the course of all evaluations of Dynamic
objects in expr
DynamicModule@8x=x0 ,y=y0 <,exprD specifies initial values for x, y, …

Localizing and initializing variables for Dynamic objects.

DynamicModule has arguments identical to Module and is similarly used to localize and initialize
variables, but there are important differences in how they operate.
 Dynamic Interactivity 7

DynamicModule has arguments identical to Module and is similarly used to localize and initialize
variables, but there are important differences in how they operate.

Here are the same two examples with "private" values of x.

In[25]:= DynamicModule@8x = .5<,
8Slider@Dynamic@xDD, Dynamic@Plot@Sin@10 y xD, 8y, 0, 2 Pi<DD<D
1.0

0.5

Out[25]= : , >
1 2 3 4 5 6

-0.5

-1.0

Notice that these two examples now work independently of each other.
In[26]:= DynamicModule@8x = .5<,
8Slider@Dynamic@xDD, Dynamic@Plot@Tan@10 y xD, 8y, 0, 2 Pi<DD<D
6

Out[26]= : , >
1 2 3 4 5 6

-2

-4

-6
 8 Dynamic Interactivity

Multiple DynamicModule s can be placed in a single output, and they maintain separate values
of the variables associated with their respective areas in the output.
In[27]:= 8DynamicModule@8x = .5<,
8Slider@Dynamic@xDD, Dynamic@Plot@Sin@10 y xD, 8y, 0, 2 Pi<DD<D,
DynamicModule@8x = .5<, 8Slider@Dynamic@xDD,
Dynamic@Plot@Tan@10 y xD, 8y, 0, 2 Pi<DD<D<
1.0

0.5

Out[27]= :: , >,
1 2 3 4 5 6

-0.5

-1.0

: , >>
1 2 3 4 5 6

-2

-4

-6

You might be tempted to use Module in place of DynamicModule, and in fact this would appear
to work at first. However, it is not a good idea for several reasons, which are discussed in more
detail in "Advanced Dynamic Functionality".

DynamicModule does its work in the front end, not in the kernel. It remains unchanged by
evaluation, and when formatted as output, it creates an invisible object embedded in the output
expression which handles the localization. As long as that space of output remains in existence
(i.e., is not deleted), the invisible object representing the DynamicModule will maintain the
values of the variables, allowing them to be used in subsequent evaluations of Dynamic expres-
sions within the scope (area) of the DynamicModule.

If you save a notebook containing a DynamicModule, close that notebook, then later reopen it
in a new Mathematica session, the values of all the local variables will still be preserved and the
sliders inside the DynamicModule will be in the same positions. This will not be the case with
sliders linked to global variables (like the earliest examples in this tutorial), nor with sliders
linked to variables localized with Module instead of DynamicModule. Such variables store their
values in the current Mathematica kernel session, and they are lost as soon as you quit Mathe-
matica.
in a new Mathematica session, the values of all the local variables will still be preserved and the
sliders inside the DynamicModule will be in the same positions. This will not be the case with
Dynamic Interactivity 9
sliders linked to global variables (like the earliest examples in this tutorial), nor with sliders
linked to variables localized with Module instead of DynamicModule. Such variables store their
values in the current Mathematica kernel session, and they are lost as soon as you quit Mathe-
matica.

In addition to localizing variables to particular regions of output, DynamicModule provides

options to automatically initialize function definitions when an expression containing a
DynamicModule is opened, and to clean up values when the expression is closed or deleted.
More details are found in DynamicModule.

The Second Argument of Dynamic

Dynamic connections are by default bi-directional. Sliders connected to a variable move
together because they both reflect and control the value of the same variable. When you drag a
slider thumb, the system constructs and evaluates expressions of the form expr = new, where
expr is the expression given in the first argument to Dynamic and new is the proposed new value
determined by where you have dragged the slider thumb. If the assignment can be done, the
new value is accepted. If the assignment fails, the slider will not move.

These two sliders move in opposite directions when you move the first one. However, trying to
move the second slider gives an error because you cannot assign a new value to the expression
1 - x.
In[1]:= DynamicModule@8x = 0<, 8Slider@Dynamic@xDD, Slider@Dynamic@1 - xDD<D

Out[1]= : , >

You can keep an arbitrary expression in the first argument of Dynamic, but change the dynami-
cally executed evaluation by using the optional second argument. This is a convenient way to
specify "inverse functions" that update the values of variables in the first arguments. Mathemat-
ica does not attempt to deduce such inverse functions automatically from the first argument of
Dynamic; you have to supply one yourself.

Dynamic@expr, f D continually evaluates f @val, exprD during interactive

changing or editing of val

Inverse functions.
 10 Dynamic Interactivity

This specifies how the value of x is to be updated and makes the second slider interactive. You
can move either slider and the other slider responds by moving in the opposite direction.
In[30]:= DynamicModule@8x = 0<, 8Slider@Dynamic@xDD, Slider@Dynamic@1 - x, Hx = 1 - ÒL &DD<D

Out[30]= : , >

Now the dynamically executed expression in the second slider is the pure function Hx = 1 - ÒL &,
which is given the proposed new value in Ò. Note that the function is responsible for actually
doing the assignment to whatever variable you want to change; you cannot just say H1 - ÒL & if
you want to change x.

The ability to interpose your own arbitrary function between the mouse position and the state
of Mathematica is very powerful, and you can use it for purposes beyond simple inverse func-
tions. The function given in the second argument is effectively free do to anything it wants.

This defines "detents" that snap the slider to integer values if the thumb is within a certain
tolerance of a round number.
In[31]:= DynamicModule@8x = 0<,
8Slider@Dynamic@x, If@Abs@Ò - Round@ÒDD < 0.1, x = Round@ÒD, x = ÒD &D, 80, 5<D,
Dynamic@xD<D
Out[31]= : , 0>

This makes the variable take on rational numbers (integer fractions) instead of decimals.
In[32]:= DynamicModule@8x = 0<,
8Slider@Dynamic@x, Hx = Rationalize@ÒDL &D, 80, 5<D, Dynamic@xD<D
Out[32]= : , 0>

For complete control over the tracking behavior, it is possible to specify separate functions that
are called at the start, middle, and end of a mouse click on the slider thumb. If you are familiar
with conventional user-interface programming, you will recognize these as separate, high-level
event functions for the mouse-down, mouse-drag, and mouse-up events.

This changes the background color while the click-and-drag operation is underway.
In[33]:= DynamicModule@8x = 0, bg = RGBColor@0, 0, 1D<, Style@Slider@Dynamic@x,
8Hbg = RGBColor@1, 0, 0DL &,
Hx = ÒL &,
Hbg = RGBColor@0, 0, 1DL &<DD, Background Ø Dynamic@bgDDD
Out[33]=

The second argument of Dynamic also lets you restrict the movement of a slider and effectively
implement geometric constraints.

You can only move the thumb of this Slider2D along a circle.
 Dynamic Interactivity 11

You can only move the thumb of this Slider2D along a circle.
In[34]:= DynamicModule@8pt = 81, 0<<,
Slider2D@Dynamic@pt, Hpt = Ò ê Norm@ÒDL &D, 8- 1, 1<, Exclusions Ø 80, 0<DD

Out[34]=

Where Should Dynamic Be Placed in an Expression?

The fundamental behavior of Dynamic is to build a copy of the input expression into the output
cell. To be more specific, Dynamic has the attribute HoldFirst and remains unchanged by
evaluation.

The result of evaluating Dynamic@x + yD is Dynamic@x + yD, which you can see by examining
the InputForm representation of the output.
In[35]:= Dynamic@x + yD êê InputForm
Out[35]//InputForm= Dynamic[x + y]

You do not see Dynamic in ordinary output because, when formatted for display in the front
end, Dynamic@x + yD is represented by an object that contains a copy of the unevaluated input
(x + y), but displays as the evaluated value of that expression. The Dynamic wrapper is still
present in the output, but it is invisible.

Because Dynamic does its work entirely in the front end, you cannot use it inside functions that
need to access the value of an expression in order to do their work.

For example, this works.

In[36]:= DynamicModule@8x<,
8Slider@Dynamic@xD, 81, 5<D, Dynamic@Plot@Sin@x iD, 8i, 0, 2 Pi<DD<D
1.0

0.5

Out[36]= : , >
1 2 3 4 5 6

-0.5

-1.0

But this does not.

 12 Dynamic Interactivity

But this does not.

In[37]:= DynamicModule@8x<,
8Slider@Dynamic@xD, 81, 5<D, Plot@Sin@Dynamic@xD iD, 8i, 0, 2 Pi<D<D
1.0

0.5

Out[37]= : , >
1 2 3 4 5 6

-0.5

-1.0

The Plot command needs to have specific numerical values for x to make a plot, but the
Dynamic@xD inside the function being plotted does not evaluate into anything in the kernel. It
remains inert as Dynamic@xD, preventing the Plot command from doing anything sensible.

Another way to look at it is that the expression inside a Plot command does not appear directly
anywhere in the output. Dynamic is a formatting function that does its work in the front end,
not in the kernel, so if it is used in a way where it will never be placed as output, it is probably
a mistake.

When combining Dynamic with controls, it is particularly important to get the Dynamic in the
right place.

This example works as expected; move the slider and the value of x changes.
In[38]:= DynamicModule@8x = 0.5<, 8Slider@Dynamic@xDD, Dynamic@xD<D

Out[38]= : , 0.5>

This example looks good at first, but if you move the slider, x does not change.
In[39]:= DynamicModule@8x = 0.5<, 8Dynamic@Slider@xDD, Dynamic@xD<D

Out[39]= : , 0.5>

That is because when the Dynamic wrapped around Slider@xD evaluates its contents, the value
of x is substituted, and the result is a slider whose first argument is a specific number, with no
trace of the variable name left. The slider in this case is a dynamic display of a static slider.

What is needed is a static slider, which contains within it a dynamic reference to the value of
the variable. In the case of controls, there is a simple rule for where to put the Dynamic. The
first argument of any control function, such as Slider, Checkbox, or PopupMenu, will almost
always be Dynamic@varD.
 Dynamic Interactivity 13

What is needed is a static slider, which contains within it a dynamic reference to the value of
the variable. In the case of controls, there is a simple rule for where to put the Dynamic. The
first argument of any control function, such as Slider, Checkbox, or PopupMenu, will almost
always be Dynamic@varD.

Beyond these cases where Dynamic will not work in a particular position, there is often a great
deal of flexibility about where to place Dynamic. It is often used as the outermost function in an
input expression, but this is by no means necessary, and in more sophisticated applications,
Dynamic is usually used deeper in the expression and can even be nested.

This displays a table of ten copies of the value of x.

In[40]:= Dynamic@Table@x, 8i, 10<DD
Out[40]= 80., 0., 0., 0., 0., 0., 0., 0., 0., 0.<

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.

The output from this example looks exactly the same.

In[41]:= Table@Dynamic@xD, 8i, 10<D
Out[41]= 80., 0., 0., 0., 0., 0., 0., 0., 0., 0.<

But in this case the Table command is evaluated immediately, generating a list of ten separate
Dynamic expressions, each of which evaluates x separately after the overall result has been
placed in the notebook.

When x is changed, the first example sends a single request to the kernel to get the value of
Table@x, 8i, 10<D, while the second example sends ten separate requests to the kernel to get
the value of x. It might seem that the first example is obviously more efficient, and in this case
it is. However, you should also avoid the other extreme, wrapping too many things into a single
Dynamic, which can also be inefficient.

This initializes x and y to set up a new slider connected to the value of x.

In[6]:= x = 0.5;

In[7]:= y = Plot3D@Sin@n mD, 8n, 0, 4<, 8m, 0, 4<D;

In[8]:= Slider@Dynamic@xDD

Out[8]=

This is a tab view with two groups of dynamic expressions, both showing the dynamic values of
x (a simple number) and y (a 3D plot).
 14 Dynamic Interactivity

This is a tab view with two groups of dynamic expressions, both showing the dynamic values of
x (a simple number) and y (a 3D plot).
In[9]:= TabView@88Dynamic@xD, Dynamic@yD<, Dynamic@8x, y<D<D

1 2
Out[9]=
80., y<

Drag the slider around, and note that the value of x in the first tab updates quite rapidly. On
most computers it will be essentially instantaneous. However, updates are more sluggish in the
second tab. Each individual Dynamic expression keeps track (quite carefully) of exactly when it
might need to be reevaluated in order to remain up-to-date. In the second tab, the output is
forcing the whole expression 8x, y<, including the large, slow 3D plot, to be reevaluated every
time the value of x changes. By using two separate Dynamic expressions in the first tab, you
allow the value of x to be updated without needing to also reevaluate y, which has not actually
changed. (You may want to delete the last output before proceeding, as it will slow down any
examples containing the global x as long as it is visible on screen.)

It is hard to make blanket statements about where Dynamic should be placed in every case, but
generally speaking if you are building a large, complex output where only small parts of it will
change, the Dynamic should probably be wrapped just around those parts. On the other hand, if
all or most of the output is going to change in response to a single variable changing its value,
then it is probably best to wrap Dynamic around the whole thing.

Dynamic in Options
Dynamic can be used on the right-hand side of options, in those cases where the option value
will be transmitted to the front end before being used. This is a somewhat subtle distinction
related to the discussion in "Where Should Dynamic Be Placed in an Expression".

An option like PlotPoints in plotting commands cannot have Dynamic on the right-hand side,
because the plotting command needs to know a specific numerical value before the plot can be
generated. Remember that Dynamic has the effect of delaying evaluation until the expression
reaches the front end, and in the case of PlotPoints, that is too late since the value is needed
right away. On the other hand, options to functions that do their work in the front end can
usually, and usefully, accept Dynamic in their option values.

For example, you can control the size of a block of text in two ways.

Dynamic can be wrapped around a whole Style expression.

 Dynamic Interactivity 15

Dynamic can be wrapped around a whole Style expression.

In[10]:= h = 12;

In[11]:= 8Slider@Dynamic@hD, 86, 100<D, Dynamic@Style@"Some Text", FontSize Ø hDD<

Out[11]= : , Some Text. >

Or Dynamic can be only in the FontSize option value.

In[59]:= 8Slider@Dynamic@hD, 86, 100<D, Style@"Some Text", FontSize Ø Dynamic@hDD<

Out[59]= : , Some Text >

There are two potential advantages to putting the Dynamic in the option value. First, suppose
the dynamically regenerated expression is very large, for example if the block of text is the
entire document, it is inefficient to retransmit it from the kernel to the front end every time the
font size is changed, as is necessary if Dynamic encloses the whole expression.

Second, the output of a Dynamic expression is not editable (since it is liable to be regenerated
at any moment), which makes the output of the first example non-editable. But the text in the
second example can be edited freely since it is ordinary static output: only the option value is
dynamic.

Dynamic option values can be also set in the Option Inspector. They are allowed at the cell,
notebook, or global level, and in stylesheets. (Note, however, that if you set a dynamic option
value in a position where the value will be inherited by many cells, for example in a stylesheet,
there can be a significant impact on performance.)

You can set dynamic option values through SetOptions , as well.

In[51]:= x = 0;

In[51]:= SetOptions@EvaluationNotebook@D, Background Ø Dynamic@Hue@xDDD

Having linked the background color of the notebook to the global variable x, it can now be
controlled by a slider or by a program.
In[52]:= Slider@Dynamic@xDD

Out[52]=

Of course, it is good to be able to return to normal.

In[53]:= SetOptions@EvaluationNotebook@D, Background Ø InheritedD

Dynamic and Infinite Loops

 16 Dynamic Interactivity

Dynamic and Infinite Loops

If you are not careful, you can easily throw Dynamic into an infinite loop.

This counts upwards as fast as possible for as long as it remains on screen.

In[54]:= DynamicModule@8x = 1<, Dynamic@x = x + 1DD

This is not a bug (but delete the above output if it is distracting you to have it there).

Because the output is updated and the screen redrawn after each cycle of an infinite loop, it is
actually quite a useful thing to be able to do. Generally speaking, the system will remain respon-
sive to typing, evaluation, and so on, even as the infinitely updating Dynamic zips along.

It is also useful to make such a self-triggering Dynamic that stops changing at some point.

This is a "droopy" slider, which always drops back to zero no matter what you drag it to.
In[55]:= DynamicModule@8x = 1<, 8VerticalSlider@Dynamic@xDD, Dynamic@x = Max@0, x - 0.01DD<D

Out[55]= : , 0>

If you have a CPU monitor running, you will see that while the slider is dropping there is a small
load on the CPU (for redrawing the screen, primarily), but once it reaches zero, the load drops
to nothing. The dynamic tracking system has noticed that the value of x did not change: there-
fore, further updating is not necessary until someone changes the value of x again (e.g., when
you click on the slider). "Advanced Dynamic Functionality" describes in more detail how the
dynamic tracking system works.

A Good Trick to Know

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.

For example, suppose you have a list of numbers you wish to be able to modify by creating one
slider to control each value.
 Dynamic Interactivity 17

For example, suppose you have a list of numbers you wish to be able to modify by creating one
slider to control each value.

This creates the list and a dynamic display of its current value.
In[1]:= data = 8.1, .5, .3, .9, .2<;

In[2]:= Dynamic@dataD
Out[2]= data

This attempts to make a table of sliders, one for each element of the list, using list@@iDD to
access the individual members.
In[3]:= Table@Slider@Dynamic@data@@iDDDD, 8i, 5<D

Out[3]= : , ,

, , >

Surprisingly, this does not work! You can see an error indication around the sliders, they cannot
be moved, and the dynamic output above never changes. You might even jump to the conclu-
sion that part extraction syntax cannot be used in this way with controls. Nothing could be
further from the truth.

The problem is that the variable i was given a temporary value by the Table command, but
that value was never used, because Dynamic is HoldFirst.

Looking at the InputForm of the table of sliders reveals the problem.

In[59]:= Table@Slider@Dynamic@data@@iDDDD, 8i, 5<D êê InputForm
Out[59]//InputForm= {Slider[Dynamic[data[[i]]]], Slider[Dynamic[data[[i]]]],
Slider[Dynamic[data[[i]]]], Slider[Dynamic[data[[i]]]],
Slider[Dynamic[data[[i]]]]}

What is needed is to do a replacement of the variable i with its temporary value, even inside
held expressions.

This can be done with ê. or with the somewhat peculiar but convenient idiomatic form demon-
strated here.
In[60]:= Table@With@8i = i<, Slider@Dynamic@data@@iDDDDD, 8i, 5<D

This output shows that Dynamic does in fact work perfectly with part extraction syntax, a very
useful property.
 18 Dynamic Interactivity

Slow Evaluations inside Dynamic

Dynamic wrapped around an expression that will take forever, or even more than just a few
seconds, to finish evaluating is a bad thing.

If you evaluate this example, you will have to wait about 5 seconds before seeing the output
$Aborted .
In[61]:= Dynamic@While@TrueDD

During the wait for the Dynamic output to evaluate, the front end is frozen, and no typing or
other action is possible. Because updating of ordinary dynamic output locks up the front end, it
is important to restrict the expressions you put inside Dynamic to things that will evaluate
relatively quickly (preferably, within a second or so). Fortunately computers, and Mathematica,
are fast, so a wide range of functions, including complex 2D and 3D plots, can easily be evalu-
ated in a fraction of a second.

To avoid locking up the front end for good, dynamic evaluations are internally wrapped in
TimeConstrained, with a timeout value of, by default, 5 seconds. (This can be changed with
the DynamicEvaluationTimeout option.) In certain extreme cases, TimeConstrained can fail to
abort the calculation, in which case the front end will, a few seconds later, put up a dialog box
allowing you to terminate dynamic updating until the offending output has been deleted.

Fortunately there is an alternative if you need to have something slow in a Dynamic. The option
SynchronousUpdating Ø False allows the dynamic to be evaluated in a way that does not lock
up the front end. During evaluation of such an asynchronous Dynamic the front end continues
operating as usual, but the main Shift +Return evaluation queue is occupied evaluating the
Dynamic, so further Shift +Return evaluations will wait until the Dynamic finishes. (Normal
synchronous Dynamic evaluations do not interfere with Shift +Return evaluations.)

Evaluate this example, and you will see a gray placeholder rectangle for about 10 seconds, after
which the result will be displayed.
In[62]:= Dynamic@8DateList@D, Pause@10D; DateList@D<, SynchronousUpdating Ø FalseD
Out[62]= 882009, 1, 2, 15, 47, 41.977359<, 82009, 1, 2, 15, 47, 51.981876<<

Importantly, during that 10-second pause you are free to continue working on other things in
the front end.

"Advanced Dynamic Functionality" gives more details about the differences between syn-
chronous and asynchronous dynamic evaluations. In general, you should not plan to use asyn-
chronous ones unless is it absolutely necessary. They do not update as quickly, and can interact
in a very surprising, though not technically incorrect, way with controls and other synchronous
 Dynamic Interactivity 19

"Advanced Dynamic Functionality" gives more details about the differences between syn-
chronous and asynchronous dynamic evaluations. In general, you should not plan to use asyn-
chronous ones unless is it absolutely necessary. They do not update as quickly, and can interact
in a very surprising, though not technically incorrect, way with controls and other synchronous
evaluations.

Further Reading
The implementation details behind Dynamic and DynamicModule are worth understanding if you
plan to use complex constructions, particularly those involving nested Dynamic expressions.
This is discussed in "Advanced Dynamic Functionality".
 20 Dynamic Interactivity

Advanced Dynamic Functionality

"Introduction to Manipulate" and "Introduction to Dynamic" provide most of the information you
need to use Mathematica's interactive features accessible through the functions Manipulate,
Dynamic, and DynamicModule. This tutorial gives further details on the workings of Dynamic
and DynamicModule and describes advanced features and techniques for achieving maximum
performance for complex interactive examples.

Many examples in this tutorial display a single output value and use Pause to simulate slow
calculations. In real life, you will instead be doing useful computations and displaying sophisti-
cated graphics or large tables of values.

Please note that this is a hands-on tutorial. You are expected to actually evaluate
each of the input lines as you reach them in your reading, and watch what hap-
pens. The accompanying text will not make sense without evaluating as you read.

Module versus DynamicModule

Module and DynamicModule have similar syntax and in many respects behave similarly, at least
at first glance. They are, however, fundamentally different in such areas as when their variables
are localized, where the local values are stored, and in what universe the variables are unique.

Module works by replacing all occurrences of its local variables with new, uniquely named
variables, constructed so that they do not conflict with any variables in the current session of
the Mathematica kernel.

You can see the names of these localized variables by allowing them to "escape" the context of
the module without having been assigned a value.
In[3]:= Module@8x<, xD
Out[3]= x$651

The local variables can be updated dynamically just like any other variables.
In[4]:= Module@8x<, Dynamic@xDD
Out[4]= x$653

That is why sliders inside Module seem to work just as well as sliders inside DynamicModule .
 Dynamic Interactivity 21

That is why sliders inside Module seem to work just as well as sliders inside DynamicModule .
In[9]:= Table@Module@8x = .5<, 8Slider@Dynamic@xDD, Dynamic@xD<D, 82<D

Out[9]= :: , 0.>, : , 0.>>

In[10]:= Table@DynamicModule@8x = .5<, 8Slider@Dynamic@xDD, Dynamic@xD<D, 82<D

Out[10]= :: , 0.5>, : , 0.5>>

Both examples produce seemingly independent sliders that allow separate settings of separate
copies of the variable x. The problem with sliders inside Module is that a different kernel session
may coincidentally share the same localized variable names. So if this notebook is saved and
then reopened sometime later, the sliders may "connect" to variables in some other Module
that happen to have the same local variables at that time.

This will not happen with the sliders inside DynamicModule because DynamicModule waits to
localize the variables until the object is displayed in the front end and generates local names
that are unique to the current session of the front end. Localization happens when
DynamicModule is first created as output and then repeats anew each time the file that contains
DynamicModule is opened, so there can never be a name conflict among examples generated in
different sessions.

Variables generated by Module are purely kernel session variables; when the kernel session
ends, the values are irretrievably lost. DynamicModule, on the other hand, generates a struc-
ture in the output cell that is responsible for maintaining the values of the variables, allowing
them to be saved in files. This is a somewhat subtle concept, best explained by way of two
analogies. First, you can think of DynamicModule as a sort of persistent version of Module.

Consider this command.

In[5]:= ModuleA8x = 2, y, z<,

x = 4;
y = x2 ;
x = 8;
z = x3 ;
E

The module in this example evaluates a series of expressions in order, and from one line to the
next the values of all the local module variables are preserved (obviously). You can have as
many lines as you like in the compound expression, but they all have to be there at the start;
once the Module has finished execution, it evaporates along with all its local variables.

DynamicModule, on the other hand, creates an environment in which evaluations of expressions

in Dynamic that appear within the body of the DynamicModule are like additional lines in the
compound expression in the previous example. From one dynamic update to the next the
 22 Dynamic Interactivity

DynamicModule, on the other hand, creates an environment in which evaluations of expressions

in Dynamic that appear within the body of the DynamicModule are like additional lines in the
compound expression in the previous example. From one dynamic update to the next the
values of all the variables are preserved, just as if the separate evaluations were separate lines
in a compound expression, all within the local variable context created by DynamicModule.

This preservation of variable values extends not just to subsequent dynamic evaluations within
the same session, but to all future sessions. Because all the local variable values are stored and
preserved in the notebook file, if the notebook is opened in an entirely new session of Mathemat -
ica, the values will still be there, and dynamic updates will resume just where they left off.
DynamicModule is like an indefinitely extendable Module.

Another way to think about the difference between Module and DynamicModule is that while
Module localizes its variables for a certain duration of time (while the body of the module is
being evaluated), DynamicModule localizes its variables for a certain area of space in the output.

As long as that space of the output remains in existence, the values of the variables defined for
it will be preserved, allowing them to be used in subsequent evaluations of Dynamic expres-
sions within the scope (area) of the DynamicModule. Saving the output into a file puts that bit
of real estate into hibernation, waiting for the moment when the file is opened again. (In com-
puter science terms, this is sometimes referred to as a freeze-dried or serialized object.)

The ability of DynamicModule to preserve state across sessions is also a way of extending the
notion of editing in a file. Normally when you edit text or expressions in a file, save the file, and
reopen it, you expect it to open the way you left it. Editing means changing the contents of a
file.

Ordinary kernel variables do not have this property; if you make an assignment to x, then quit
and restart Mathematica, x does not have that value anymore. There are several reasons for
this, not least of which is the question of where the value of x should be saved.

DynamicModule answers this question by defining a specific location (the output cell) where
values of specific variables (the local variables) should be preserved. Arbitrary editing opera-
tions, like moving a slider, typing in an input field, or dragging a dynamic graphics object,
change the values of the local variables. And since these values are automatically preserved
when the file is saved, the sliders, and other objects, open exactly where they were left. Thus
DynamicModule lets you make any quantity editable in the same way that text and expressions
can be edited and saved in notebook files.

Front End Ownership of DynamicModule Variable

 Dynamic Interactivity 23

Front End Ownership of DynamicModule Variable

Values
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. The same is true of dynamic output that refers to the
values of ordinary variables.

Consider this example.

In[6]:= x = 0;

In[6]:= Table@Slider@Dynamic@xDD, 8500<D

Out[7]= : , , …>

When one slider is moved, the other 499 move in sync with it. This requires 500 separate
transactions with the kernel to retrieve the value of x. (The semantics of Mathematica are
complex enough that there is no guarantee that evaluating x several times in a row will actually
return the same value each time: it would not be possible for the front end to improve effi-
ciency by somehow sharing a single value retrieved from the kernel with all the sliders.)

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.

The following example thus runs noticeably faster.

In[8]:= DynamicModule@8x = 0<, Table@Slider@Dynamic@xDD, 8500<DD

Out[8]= : , , …>

If a complex function is applied to such a variable, its value must of course be sent to the
kernel. This happens transparently, with each side of the system being kept informed on a just-
in-time basis of any changes to variable values.

Whether it is better to use a normal kernel variable or a DynamicModule variable in a given

situation depends on a number of factors. The most important is the fact that values of all
DynamicModule variables are saved in the file when the notebook is saved. If you need a value
preserved between sessions, it must be declared in a DynamicModule. On the other hand, a
temporary variable holding a large table of numbers, for example, might be a poor choice for a
DynamicModule variable as it could greatly increase the size of the file. It is quite reasonable to
Whether it is better to use a normal kernel variable or a DynamicModule variable in a given
24 Dynamic Interactivity
situation depends on a number of factors. The most important is the fact that values of all
DynamicModule variables are saved in the file when the notebook is saved. If you need a value
preserved between sessions, it must be declared in a DynamicModule. On the other hand, a
temporary variable holding a large table of numbers, for example, might be a poor choice for a
DynamicModule variable as it could greatly increase the size of the file. It is quite reasonable to
nest a Module inside a DynamicModule and vice versa, or to partition variables between the
front end and kernel.

In many situations the limiting factor in performance is the time needed to retrieve information
from the kernel: by making variables local to the front end, speed can sometimes be increased
dramatically.

Automatic Updates of Dynamic Objects

The specification for dynamic output is simple: Dynamic@exprD should always display the value
you would get if you evaluated expr now. If a variable value, or some other state of the system,
changes, the dynamic output should be updated immediately. Of course, for efficiency, not
every dynamic output should be reevaluated every time any variable changes. It is critical that
dependencies be tracked so that dynamic outputs are evaluated only when necessary.

Consider these two expressions.

In[9]:= Dynamic@a + b + cD
Out[9]= a + b + c

In[10]:= Dynamic@If@a, b, cDD

Out[10]= If@a, b, cD

The first expression might change its value any time the value of a, b, or c changes, or if any
patterns associated with a, b, or c are changed. The second expression depends on a and b (but
not c) while a is True and on a and c (but not b) while a is False. If a is neither True nor False,
then it depends only on a (because the If statement returns unevaluated).

Figuring out these dependencies a priori is impossible (there are theorems to this effect), so
instead the system keeps track of which variables or other trackable entities are actually encoun -
tered during the process of evaluating a given expression. Data is then associated with those
variable(s) identifying which dynamic expressions need to be notified if the given variable
receives a new value.

An important design goal of the system is to allow monitoring of variable values by way of
dynamic output referencing them, without imposing any more load than absolutely necessary
on the system, especially if the value of the variable is being changed rapidly.
 Dynamic Interactivity 25

An important design goal of the system is to allow monitoring of variable values by way of
dynamic output referencing them, without imposing any more load than absolutely necessary
on the system, especially if the value of the variable is being changed rapidly.

Consider this simple example.

In[11]:= Dynamic@xD
Out[11]= x

In[13]:= Do@x, 8x, 1, 5 000 000<D

When the dynamic output is created, it is evaluated, and the symbol x is tagged with informa-
tion identifying the output that needs to be updated if its value should be changed.

When the loop is started and x is first given a new value, the data associated with it is con-
sulted, and the front end is notified that the dynamic output needs to be updated. The data
associated with x is then deleted. Essentially the system forgets all about the dynamic output,
and subsequent assignments in the loop incur absolutely no speed penalty because of the
existence of a dynamic output monitoring the value of x.

Much later (on a computer time scale; only a fraction of a second on a human time scale) when
the screen is next redrawn and the dynamic output containing the reference to x is reevaluated,
the connection between the dynamic output and the variable x is noticed again, and the associa-
tion is reestablished.

Meanwhile the loop has continued to run. The next time the assignment is done after the screen
is updated, another notification will be sent to the front end, and the process repeats.

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"). In the previous example you will typically see the value jump by
tens or hundreds of thousands with each update (more the faster your computer is), and the
overall speed of the computation is slowed down by only a percent or two, nearly zero if you
have a multiprocessor system.

You might expect that having a dynamic output monitoring the value of a symbol that is being
changed rapidly in a tight loop would slow that loop down significantly. But the overhead is in
fact zero-order in the rate at which the variable is changed, and in practice is usually minimal.

Dynamic outputs are only updated when they are visible on screen. This optimization allows
you to have an open-ended number of dynamic outputs, all changing constantly, without incur-
ring an open-ended amount of processor load. Outputs that are scrolled off-screen, above or
below the current document position, will be left unexamined until the next time they are
 26 Dynamic Interactivity

Dynamic outputs are only updated when they are visible on screen. This optimization allows
you to have an open-ended number of dynamic outputs, all changing constantly, without incur-
ring an open-ended amount of processor load. Outputs that are scrolled off-screen, above or
below the current document position, will be left unexamined until the next time they are
scrolled on-screen, at which point they are updated before being displayed. (Thus the fact that
they stopped updating is not normally apparent, unless they have side effects, which is discour-
aged in general.)

Dynamic output can depend on things other than variables, and in these cases tracking is also
done carefully and selectively.

This gives a rapidly updated display of the current mouse position in screen coordinates.
In[14]:= Dynamic@MousePosition@DD
Out[14]= 81058, 553<

As long as the output is visible on screen, there will be a certain amount of CPU activity any
time the mouse is moved, because this particular dynamic output is being redrawn immediately
with every movement of the mouse. But if it is scrolled off-screen, the CPU usage will vanish.

Refresh
Normally, dynamic output is updated whenever the system detects any reason to believe it
might need to be (see "Automatic Updates of Dynamic Objects" for details about what this
means). Refresh can be used to modify this behavior by specifying explicitly what should or
should not trigger updates.

This updates when either slider is moved.

In[15]:= DynamicModule@8x, y<, Column@8
Slider@Dynamic@xDD,
Slider@Dynamic@yDD,
Dynamic@8x, y<D<DD

Out[15]=

80.245, 0.11<

Refresh with a TrackedSymbols option can be used to specify a list of those symbols that
should be tracked, with all other reasons for updating being ignored.
 Dynamic Interactivity 27

This updates only when x changes, ignoring changes in y.

In[16]:= DynamicModule@8x, y<, Column@8
Slider@Dynamic@xDD,
Slider@Dynamic@yDD,
Dynamic@Refresh@8x, y<, TrackedSymbols Ø 8x<DD<DD

Out[16]=

80.065, 0.<

When you move the second (y) slider, nothing happens, but when you move the first slider, the
expression is updated to reflect the current value of both variables. You might say that after
moving the second slider, the dynamic output is wrong, since it does not reflect the current
state of the system. But that is essentially the whole reason for the existence of the Refresh
command. It allows you to override the system's mandate to always update dynamic output
any time it is potentially out of date.

The setting TrackedSymbols -> Automatic can be used to track only those symbols that occur
explicitly (lexically) in the expression given in the first argument to Refresh. For example, if
you use a function that depends on a global variable that does not occur lexically inside
Refresh, changes to the value of the global variable will not cause updating, when normally
they would.

Refresh can also be used to cause updates at regular time intervals. It is important to unders-
tand that this is not a feature that should be used lightly. It is fundamental to the design of
Dynamic that it does not need to update on any fixed schedule, because it simply always
updates immediately whenever doing so would be useful. But there are some situations where
this either cannot, or just unfortunately does not, happen.

One potentially vexing case is RandomReal. Every time you evaluate RandomReal@D, you get a
different answer, and you might think that Dynamic@RandomReal@DD should therefore con-
stantly update itself as fast as possible. But this would normally not be useful, and would in fact
have negative consequences for a number of algorithms that use randomness internally (e.g., a
Monte Carlo integration inside Dynamic should probably not update constantly simply because it
will, in fact, give a slightly different answer each time).

For this reason, RandomReal@D is not "ticklish," in the sense that it does not trigger updates. If
you want to see new random numbers, you have to use Refresh to specify how frequently you
want the output updated. Another example of non-ticklish functions are file system operations.

This gives you a new number every second.

 28 Dynamic Interactivity

This gives you a new number every second.

In[17]:= Dynamic@Refresh@RandomReal@D, UpdateInterval Ø 1DD
Out[17]= 0.722136

This is not updated automatically.

In[18]:= Dynamic@FileByteCount@ToFileName@
8$TopDirectory, "SystemFiles", "FrontEnd", "Palettes"<, "BasicMathInput.nb"DDD
Out[18]= $Failed

In the unlikely event that the file containing the BasicMathInput palette changes size, this
Dynamic will not be updated. If you want to monitor the size of a file, you need to use Refresh
to specify a polling interval. (On sufficiently advanced operating systems it would theoretically
be possible for Mathematica to efficiently receive notifications of file system activity, and future
versions of Mathematica might in fact update such expressions automatically. As with other
Dynamic expressions, automatic correctness is always the goal.)

Finally, several functions you might think would trigger dynamic updates in fact do not: for
example, DateList and AbsoluteTime. As with RandomReal, it would cause more trouble than
it is worth for these functions to automatically trigger updates, and Refresh can trivially be
used to create clock-like objects. The function Clock is intended specifically as a time-based
function that is ticklish.

This updates approximately every second.

In[19]:= Dynamic@Refresh@DateList@D, UpdateInterval Ø 1DD
Out[19]= 82009, 1, 2, 17, 3, 24.196806<

This updates without an explicit Refresh .

In[26]:= Dynamic@Clock@81, 10<DD

Nesting Refresh
In the Refresh section examples, Refresh is always the outermost function inside Dynamic. You
might almost wonder why its options are not simply options to Dynamic. But in fact it is often
important to place Refresh as deeply in the expression as possible, especially if it specifies a
time-based updating interval.
 Dynamic Interactivity 29

Consider this example.

In[20]:= DynamicModule@8showclock = True<, 8Checkbox@Dynamic@showclockDD,
Dynamic@If@showclock, Refresh@DateList@D, UpdateInterval Ø 0.05D, "No clock"DD<D
Out[20]= 9 , No clock=

When the checkbox is checked, Refresh is causing frequent updating of the clock, and CPU
time is being consumed to keep things up-to-date. When the checkbox is unchecked, however,
the Refresh expression is no longer reached by evaluation, the output remains static, and no
CPU time is consumed. If Refresh were wrapped around the whole expression inside Dynamic,
CPU time would be consumed constantly, even if the clock were not being displayed. The words
"No clock" would be constantly refreshed, pointlessly. (This refreshing is not visible; there is no
flicker of the screen, but CPU time is being consumed nevertheless.)

Nesting Dynamic
Dynamic expressions can be nested, and the system takes great care to update them only when
necessary. Particularly when the contents of a Dynamic contain further interactive elements, it
is important to keep track of what will stay static and what will update, when a given variable is
changed.

Consider this example.

In[21]:= DynamicModule@8n = 5, data = Table@RandomReal@D, 820<D<,
Column@8
Slider@Dynamic@nD, 81, 20, 1<D,
Dynamic@Column@Table@With@8i = i<, Slider@Dynamic@data@@iDDDDD, 8i, n<DDD<DD

Out[21]=

The position of the first slider determines the number of sliders underneath it, and each of
those sliders in turn is connected to the value of one element of a list of data. Because the
number of sliders is variable, and changes dynamically in response to the position of the first
slider, the table that generates them needs to be inside Dynamic.

The example works, but now suppose you want to display the value of each number in the list
next to its slider.
 30 Dynamic Interactivity

The example works, but now suppose you want to display the value of each number in the list
next to its slider.

You might at first try this.

In[22]:= DynamicModule@8n = 5, data = Table@RandomReal@D, 820<D<,
Column@8
Slider@Dynamic@nD, 81, 20, 1<D,
Dynamic@Grid@Table@With@8i = i<,
8Slider@Dynamic@data@@iDDDD, data@@iDD<D, 8i, n<D
DD<DD

0.0772513

0.078808
Out[22]=
0.627453

0.165515

0.441267

Now any time you click one of the lower sliders, it moves only one step, then stops. The prob-
lem is that the data@@iDD expressions in the second column of the grid are creating a depen-
dency in the outer Dynamic on the values in data.

As soon as data changes, the contents of the outer Dynamic, including the slider you are trying
to drag, are destroyed and replaced with a nearly identical copy (in which the displayed value of
one of the data@@iDD has been changed). In other words, the act of dragging the slider destroys
it, preventing any further activity.

The solution to this is to prevent the outer Dynamic from depending on the value of data, by
making sure that all occurrences of data in the expression are wrapped in Dynamic .
In[23]:= DynamicModule@8n = 5, data = Table@RandomReal@D, 820<D<,
Column@8
Slider@Dynamic@nD, 81, 20, 1<D,
Dynamic@Grid@Table@With@8i = i<,
8Slider@Dynamic@data@@iDDDD, Dynamic@data@@iDDD<D, 8i, n<D
DD<DD

0.858271

0.729104
Out[23]=
0.355231

0.581138

0.779463

Now you can drag any of the sliders and see dynamically updated values. This works because
the outer Dynamic now depends only on the value of n, the number of sliders, not on the value
of data. (Technically this is because Dynamic is HoldFirst: when it is evaluated, the expression
 Dynamic Interactivity 31

Now you can drag any of the sliders and see dynamically updated values. This works because
the outer Dynamic now depends only on the value of n, the number of sliders, not on the value
of data. (Technically this is because Dynamic is HoldFirst: when it is evaluated, the expression
in its first argument is never touched by evaluation, and therefore no dependencies are
registered.)

When building large, complex interfaces using multiple levels of nested Dynamic expressions,
these are important issues to keep in mind. Mathematica works hard to do exactly the right
thing even in the most complex cases. For example, the output of Manipulate consists of a
highly complex set of interrelated and nested Dynamic expressions: if the dependency tracking
system did not work correctly, Manipulate would not work right.

Synchronous versus Asynchronous Dynamic

Evaluations
Mathematica consists of two separate processes, the front end and the kernel. These really are
separate processes in the computer science sense of the word: two independent threads of
execution with separate memory spaces that show up separately in a CPU task monitor.

The front end and kernel communicate with each other through several MathLink connections,
known as the main link, the preemptive link, and the service link. The main and preemptive
links are pathways by which the front end can send evaluation requests to the kernel, and the
kernel can respond with results. The service link works in reverse, with the kernel sending
requests to the front end.

The main link is used for Shift +Return evaluations. The front end maintains a queue of pending
evaluation requests to send down this link. When you use Shift +Return on one or more input
cells, they are all added to the queue, and then processed one by one. At any one time, the
kernel is only aware of a single main link evaluation, the one it is currently working on (if any).
In the meantime, the front end remains fully functional; you can type, open and save files, and
so on. There is no arbitrary limit on how long a main link evaluation can reasonably take. Peo-
ple routinely do evaluations that take days to complete.

The preemptive link works the same way as the main link in the sense that the front end can
send an evaluation to it and get an answer, but it is administered quite differently on both
Dynamic updates.
There is no queue; instead, the front end sends one evaluation at a time and waits for the
result before continuing with its other work. It is thus important to limit preemptive link evalua-
tions to a couple of seconds at most. During any preemptive link evaluation, the front end is
 32 Dynamic Interactivity

ends. On the front end side, the preemptive link is used to handle normal Dynamic updates.
There is no queue; instead, the front end sends one evaluation at a time and waits for the
result before continuing with its other work. It is thus important to limit preemptive link evalua-
tions to a couple of seconds at most. During any preemptive link evaluation, the front end is
completely locked up, and no typing or other actions are possible.

On the kernel side, evaluation requests coming from the preemptive link are given priority over
evaluations from the main link, including the current running main link evaluation (if any). If an
evaluation request comes from the preemptive link while the kernel is processing a main link
evaluation, the main link evaluation is halted at a safe point (usually within microseconds). The
preemptive link evaluation is then run to completion, after which the main link evaluation is
restarted and allowed to continue as before. The net effect is similar to, though not the same
as, a threading mechanism. Multiple fast preemptive link evaluations can be executed during a
single long, slow main link evaluation, giving the impression that the kernel is working on more
than one problem at a time.

Preemptive link evaluations can change the values of variables, including those being used by a
main link evaluation running at the same time. There is no paradox here, and the interleaving
is done in a way that is entirely safe, though it can result in some fairly peculiar behavior until
you understand what is going on.

For example, evaluate this to get a slider.

In[24]:= Slider@Dynamic@xDD

Out[24]=

Then evaluate this command, and during the ten seconds it takes to finish, drag the slider
around randomly.
In[25]:= Table@Pause@1D; x, 810<D
Out[25]= 80, 0.2, 0., 0., 0., 0.5, 0.675, 0., 0., 0.<

You will not see anything happening (other than the slider moving) but when the second evalua-
tion finishes, you will see that it has recorded ten different values of x, representing the posi-
tions the slider happened to be at during the ten points at which x was evaluated to build the
list.

Dynamic normally uses the preemptive link for its evaluations. Evaluation is synchronous, and
the front end locks up until it is finished. This is unavoidable in some cases, but can be subopti-
mal in others. By setting the option SynchronousUpdating -> False, you can tell the front end
to use the main link queue, rather than the preemptive link. The front end then displays a gray
box placeholder until it receives the response from the kernel.
 Dynamic Interactivity 33

Dynamic normally uses the preemptive link for its evaluations. Evaluation is synchronous, and
the front end locks up until it is finished. This is unavoidable in some cases, but can be subopti-
mal in others. By setting the option SynchronousUpdating -> False, you can tell the front end
to use the main link queue, rather than the preemptive link. The front end then displays a gray
box placeholder until it receives the response from the kernel.

In this case, the default (synchronous) update is appropriate because the front end needs to
know the result of evaluating the Dynamic@xD for drawing with the correct font size.
In[26]:= DynamicModule@8x = 12<,
8Slider@Dynamic@xD, 810, 100<D, Style@"Hello", FontSize Ø Dynamic@xDD<D
Out[26]= : , Hello>

Here, the output cell is drawn before the second dynamic expression finishes. A gray box
placeholder persists for one second until the result is known. Reevaluate the example to see the
gray box again.
In[27]:= DynamicModule@8n = 1<, Column@8Slider@Dynamic@nD, 81, 10<D,
Dynamic@Pause@nD; n, SynchronousUpdating Ø FalseD<DD

Out[27]=
1

Clicking the slider will update the display with a delay of between one and ten seconds. Notice
that the cell bracket is outlined, just as if the cell were being Shift +Return evaluated. This is an
indication that the evaluation is queued, and that you can continue with other work in the front
end while the evaluation is progressing.

Asynchronous updating is useful for displaying full Dynamic subexpressions when it is possible
to draw a screen around them and fill in their value later, in much the same way a web browser
draws text around an image that is inserted later when it finishes downloading.

Why not always use asynchronous Dynamic expressions? There are several reasons. First, they
are queued so that, by definition, they do not operate while another Shift +Return evaluation is
underway. This is not the case for normal (synchronous) updates.

A synchronous Dynamic updates smoothly even if the Pause command above is running.
In[28]:= Pause@20D

In[29]:= DynamicModule@8n = 1<, Column@8Slider@Dynamic@nD, 81, 10<D, Dynamic@nD<DD

Out[29]=
1

Also, many controls need to be synchronous in order to be responsive to mouse actions. Making
them asynchronous may cause potentially strange interactions with other controls.
 34 Dynamic Interactivity

Also, many controls need to be synchronous in order to be responsive to mouse actions. Making
them asynchronous may cause potentially strange interactions with other controls.

Here is a problematic example.

In[30]:= n = 1;
Column@8Slider@Dynamic@nD, 81, 10<D,
Dynamic@Graphics@Line@Table@8x, Sin@n xD<, 8x, 0, 2 Pi, 0.0001<DDD,
SynchronousUpdating Ø FalseD<D

Out[31]=

Move the slider around rapidly, and you will end up with a choppy, distorted sine wave, because
the value of n changed during the evaluation of the Table command. This is the correct,
expected behavior, but it is probably not what you wanted.

This problem does not occur if you use synchronous Dynamic expressions, generally does not
happen with DynamicModule local variables, and can be avoided by storing the value of any
potentially changing variables into a second variable before starting the asynchronous evalua-
tions.

This fixes the problem.

In[32]:= n = 1;
Column@8Slider@Dynamic@nD, 81, 10<D, Dynamic@
Module@8n1 = n<, Graphics@Line@Table@8x, Sin@n1 xD<, 8x, 0, 2 Pi, 0.0001<DDDD,
SynchronousUpdating Ø FalseD<D

Out[33]=
 Dynamic Interactivity 35

ControlActive and SynchronousUpdatingÆAutomatic

As a general rule, if you have a Dynamic that is meant to respond interactively to the move-
ments of a slider or other continuous-action control, it should be able to evaluate in under a
second, preferably well under. If the evaluation takes longer than that, you are not going to get
satisfactory interactive performance, whether the Dynamic is updating synchronously or
asynchronously.

But what if you have an example that simply cannot finish evaluating fast enough, yet you want
to be able to make it respond to a slider? One option is to use asynchronous updating and
simply accept that you will not get real-time interactive performance. If that is what you want
to do, setting ContinuousAction -> False in the slider or other control is a good idea; that
way you get only one update after the control is released, avoiding the starting up of potentially
lengthy evaluations in the middle of a drag, before you have arrived at the value you want to
stop at.

The cell bracket becomes outlined, indicating evaluation activity, only after you release the
slider.
In[34]:= DynamicModule@8n = 1<,
Column@8Slider@Dynamic@nD, 81, 10<, ContinuousAction Ø FalseD,
Dynamic@Pause@nD; n, SynchronousUpdating Ø FalseD<DD

Out[34]=
1

Another, much better solution is to provide a fast-to-compute preview of some sort during the
interactive control dragging operation, then compute the full, slow output when the control is
released. Several features exist specifically to support this.

The first is the function ControlActive, which returns its first argument if a control is currently
being dragged, and its second argument if not. Unlike Dynamic, ControlActive is an ordinary
function that evaluates in the kernel, returning one or the other of its arguments immediately.
It can be embedded inside functions or option values.

The second feature is an option setting SynchronousUpdating -> Automatic for Dynamic,
which makes the Dynamic synchronous when a control is being dragged, and asynchronous
when the control is released. Together, these two features can be used to implement a fast,
synchronously updated display to be used while a control is being dragged, along with a slower,
asynchronously updated display when it is released.

The displayed text changes depending on whether or not the slider is being dragged.
 36 Dynamic Interactivity

The displayed text changes depending on whether or not the slider is being dragged.
In[35]:= DynamicModule@8n = 1<, Column@8Slider@Dynamic@nD, 81, 10<D,
Dynamic@8n, ControlActive@"Active", "Not Active"D<D<DD

Out[35]=
81, Not Active<

A simple number is displayed, synchronously, while the slider is being dragged, and when it is
released, a graphic is generated asynchronously.
In[36]:= DynamicModule@8n = 3<,
Column@8Slider@Dynamic@nD, 83, 1000, 1<D, Dynamic@Graphics@ControlActive@Inset@n,
80, 0<D, Line@Table@880, 0<, 8Cos@tD, Sin@tD<<, 8t, 0., 2 Pi, 2 Pi ê n<DDD,
ImageSize Ø 300, PlotRange Ø 1D, SynchronousUpdating Ø AutomaticD<DD

Out[36]=

This example shows that the front end can remain responsive no matter how long the final
display takes to compute and that the preview and the final display can be completely different.

Of course, in most cases, you will want a preview that is some kind of reduced, thinned out,
skeletal, or other elided form of the final display. Then the crude form can be fast enough to
give a smooth preview, and the computation of the final version, even if it takes awhile, does
not block the front end. In fact, this behavior is so useful that it is the default in Plot3D and
other plotting functions.
 Dynamic Interactivity 37

This displays a 3D plot with a very small number of plot points while the control is being
dragged and then refines the image with a large number of plot points when the control is
released.
In[37]:= DynamicModule@8n = 1<,
Column@8Slider@Dynamic@nD, 81, 5<D, Dynamic@Plot3D@Sin@n x yD, 8x, 0, 3<,
8y, 0, 3<, PlotPoints Ø ControlActive@10, 100D, MaxRecursion Ø 0D,
SynchronousUpdating Ø AutomaticD<DD

Out[37]=

By default, Plot3D produces a similar preview, though with a somewhat less extreme spread of
quality.
In[38]:= DynamicModule@8n = 1<, Column@8Slider@Dynamic@nD, 81, 5<D, Dynamic@
Plot3D@Sin@n x yD, 8x, 0, 3<, 8y, 0, 3<D, SynchronousUpdating Ø AutomaticD<DD

Out[38]=
 38 Dynamic Interactivity

In addition, Manipulate uses SynchronousUpdating -> Automatic in Dynamic by default

so the example becomes as simple as it can be.
In[39]:= Manipulate@Plot3D@Sin@n x yD, 8x, 0, 3<, 8y, 0, 3<D, 8n, 1, 5<D

Out[39]=

You may have noticed one subtlety. When the output of either of the above three examples is
first placed in the notebook, you see a crudely drawn (control-active state) version, followed
shortly thereafter by a refined (control-inactive) version. This is intentional: the system is
providing a fast preview so you see something rather than just a gray rectangle. The first
update is done synchronously, just as if a control were being dragged.

This preview-evaluation behavior is examined in more detail in the next section.

ImageSizeCache in Dynamic
ImageSizeCache is an option to Dynamic that specifies a rectangular size to be used in
displaying a Dynamic whose value has not yet been computed. It is normally not specified in
input, but is instead generated automatically by the front end and saved in files along with the
Dynamic expression.

The interaction of ControlActive, SynchronousUpdating, and ImageSizeCache is subtle,

complex, and very useful. The first two constructs are explained in ControlActive and Syn-
chronousUpdatingØAutomatic. The remaining part is explained here.

Note first that Dynamic expressions with the default value of SynchronousUpdating -> True
will never have a chance to use the value of their ImageSizeCache option, because they are
always computed before being displayed, and, once computed, the actual image size will be
 Dynamic Interactivity 39

Note first that Dynamic expressions with the default value of SynchronousUpdating -> True
will never have a chance to use the value of their ImageSizeCache option, because they are
always computed before being displayed, and, once computed, the actual image size will be
used.

On the other hand, Dynamic expressions with SynchronousUpdating Ø False will be displayed
as a gray rectangle while they are being computed for the first time. In that case, the size of
the rectangle is determined by the value of the ImageSizeCache option. This allows the sur-
rounding contents of the notebook to be drawn in the right place, so that when the Dynamic
finishes updating, there is no unnecessary flicker and shifting around of the contents of the
notebook. (Users of HTML will recognize this as the analog of the width and height parameters
of the img tag.)

It is generally not necessary to specify the ImageSizeCache option explicitly, because the
system will set it automatically as soon as the value of the Dynamic is computed successfully.
(The computed result is measured, and the actual size copied into the ImageSizeCache option.)
This automatically computed value is preserved if the Dynamic output is saved in a file.

Consider the following input.

In[40]:= Dynamic@Pause@3D; Style@"Hello", 100D, SynchronousUpdating Ø FalseD

Out[40]= Hello
When the input expression is evaluated, a small gray rectangle appears; because this Dynamic
has never been evaluated, there is no cache of its proper image size, and a default small size is
used.

Three seconds later, the result arrives, and the dynamic output is displayed. At this point an
actual size is known, and is copied to the ImageSizeCache option. You can see the value by
clicking anywhere in the output cell and choosing Show Expression from the Cell menu. (This
shows you the underlying expression representing the cell, exactly as it would appear in the
notebook file if you were to save this cell.) Note the presence of an ImageSizeCache option.

Now type a space in some innocuous place in the raw cell expression (to force a reparsing of
the cell contents), and choose Show Expression again to reformat the cell. This time you will
see a gray rectangle the size of the final output for three seconds, followed by the proper out-
put. This is also what you would see if you opened a notebook containing previously saved,
asynchronous dynamic output.
 40 Dynamic Interactivity

Now type a space in some innocuous place in the raw cell expression (to force a reparsing of
the cell contents), and choose Show Expression again to reformat the cell. This time you will
see a gray rectangle the size of the final output for three seconds, followed by the proper out-
put. This is also what you would see if you opened a notebook containing previously saved,
asynchronous dynamic output.

The behavior of the setting SynchronousUpdating -> Automatic is similar, but subtly different.
As we saw in the examples in "ControlActive and SynchronousUpdatingØAutomatic", with the
Automatic setting, a synchronous preview-evaluation is done when the output is first placed, to
provide a (hopefully) rapid display of the contents of the Dynamic expression before the slower,
asynchronous value is computed. Because the first evaluation is synchronous, no gray rectangle
is ever displayed.

But this preview evaluation is done only if the ImageSizeCache option is not present. A Dynamic
with SynchronousUpdating -> Automatic and an ImageSizeCache option specifying explicit
dimensions will not do a synchronous preview evaluation, and will instead display a gray rectan-
gle (of the correct size) pending the result of the first asynchronous evaluation.

This may seem like baffling behavior at first, until you consider the practical effect of it. Gener-
ally speaking, Dynamic expressions will always have an ImageSizeCache option (created auto-
matically by the front end) except for the very first time they appear, when they are originally
placed as output from an evaluation. Any time they are opened from a file they will have a
known, cached size.

In Manipulate, which accounts for the vast majority of dynamic outputs, the default setting is
SynchronousUpdating -> Automatic and the described behavior lets the output show up
cleanly with a preview image in place when it is first generated. When a file containing dozens
of Manipulate outputs is opened, you will get a useful behavior that is familiar from web
browsers: the text displays immediately, and graphics (and other dynamic content) fill in later
as fast as they are able. So you can scroll through a file rapidly, without any delay associated
with precomputing potentially many preview images before the first page of the file can be
displayed.

If the initial evaluations when the Manipulate output was first placed were not synchronous,
there would be flicker and resizing/shifting of the surroundings, because the size would not be
known. But when the Manipulate output is opened from a file, the size is known, and the final
output can be placed smoothly without flicker.

One-Sided Updating of ControlActive

 Dynamic Interactivity 41

One-Sided Updating of ControlActive

After evaluating in the kernel, ControlActive can trigger an update of the Dynamic containing
it, but in a highly asymmetric fashion, only when it is going from the active to the inactive
state. When making a transition in the other direction, from inactive to active, ControlActive
does not trigger any update on its own.

The reason for this somewhat unusual behavior is that ControlActive is a completely global
concept. It returns the active state if any control anywhere in Mathematica is currently being
dragged~even controls that have nothing to do with a particular Dynamic that happen to
contain a reference to ControlActive. If ControlActive caused updates on its own, then as
soon as you clicked any control, all Dynamic expressions containing references to
ControlActive (e.g., a default dynamic Plot3D output) would immediately update, which
would be entirely pointless. Instead, only those outputs that have some other reason for
updating will pick up the current value of ControlActive.

On the other hand, when the control is released, it is desirable to fix up any outputs that were
drawn in control-active form, to give them their final polished appearance. Thus, when
ControlActive is going into its inactive state, it needs to, on its own, issue updates to any
Dynamic expression that may have been drawn in the active state.

Dragging the slider does not change the Active/Inactive display because ControlActive does
not trigger updates on its own.
In[49]:= DynamicModule@8x<,
8Slider@Dynamic@xDD, Dynamic@ControlActive@"Active", "Inactive"DD<D
Out[49]= : , Inactive>

This Active/Inactive display updates because x in the dynamic output changes.

In[41]:= DynamicModule@8x<,
8Slider@Dynamic@xDD, Dynamic@8x, ControlActive@"Active", "Inactive"D<D<D
Out[41]= : , 80., Inactive<>

Watch carefully what happens when you click the slider. If you click and hold the mouse without
moving it, the display will remain Inactive. But as soon as you move it, the display updates to
Active. This is happening because x changed, causing the Dynamic as a whole to update, thus
picking up the current state of ControlActive.

Now carefully release the mouse button without moving the mouse. Note that the display does
revert to Inactive even though x has not changed.
 42 Dynamic Interactivity

Now carefully release the mouse button without moving the mouse. Note that the display does
revert to Inactive even though x has not changed.

DynamicModule Wormholes
The variables declared in a DynamicModule are localized to a particular rectangular area within
one cell in a notebook. There are situations in which it is desirable to extend the scope of such
a local variable to other cells or even other windows. For example, you might want to have a
button in one cell that opens a dialog box that allows you to modify the value of a variable
declared in the same scope as the button that opened the dialog.

This can be done with one of the more surreal constructs in Mathematica, a DynamicModule
wormhole. DynamicModule accepts the option DynamicModuleParent, whose value is a
NotebookInterfaceObject that refers to another DynamicModule anywhere in the front end.
For purposes of variable localization, the DynamicModule with this option will be treated as if it
resided inside the one referred to, regardless of where the two actually are (even if they are in
separate windows).

The tricky part in setting up such a wormhole is getting the NotebookInterfaceObject neces-
sary to refer to the parent DynamicModule. This reference can be created only after the
DynamicModule has been created and placed as output, and it is valid only for the current
session.

To make the process easier, and in fact avoid all reference to explicit
NotebookInterfaceObjects, DynamicModule also accepts the option InheritScope, which
automatically generates the correct value of the DynamicModuleParent option to make the new
DynamicModule function as if it were inside the scope of the DynamicModule from which it was
created. This is confusing, so an example is in order.

Evaluate this to create an output with a + button and a number.

In[42]:= DynamicModule@8x = 1<, 8Button@"+", ++xD, Button@"Make - Palette", CreatePalette@
DynamicModule@8<, Button@"-", --xD, InheritScope Ø TrueDDD, Dynamic@xD<D

Out[42]= : + , Make - Palette , 1>

Clicking the + button increments the value of a DynamicModule local variable, which is
displayed at the end of the output. To decrement the number you have to click the Make -
Palette button, which creates a new (very small) floating palette window containing a - button.

This - button is living in a wormhole created by the InheritScope option of the DynamicModule
containing it. Clicking the button decrements the value of a local, private variable in the scope
 Dynamic Interactivity 43

This - button is living in a wormhole created by the InheritScope option of the DynamicModule
containing it. Clicking the button decrements the value of a local, private variable in the scope
of a distant DynamicModule in another window.

InheritScope can be used only when the code creating the second DynamicModule is executed
from inside a button or other dynamic object located within the first DynamicModule. By using
DynamicModuleParent explicitly, it is possible to link up arbitrary existing DynamicModules, but
doing so is tricky, and beyond the scope of this document.
 44 Dynamic Interactivity

Introduction to Manipulate
The single command Manipulate lets you create an astonishing range of interactive applica-
tions with just a few lines of input. Manipulate is designed to be used by anyone who is comfort-
able using basic commands such as Table and Plot: it does not require learning any compli-
cated new concepts, nor any understanding of user interface programming ideas.

The output you get from evaluating a Manipulate command is an interactive object containing
one or more controls (sliders, etc.) that you can use to vary the value of one or more parame-
ters. The output is very much like a small applet or widget: it is not just a static result, it is a
running program you can interact with.

This tutorial is designed for people who are familiar with the basics of using the Mathematica
language, including how to use functions, the various kinds of brackets and braces, and how to
make simple plots. Some of the examples will use more advanced functions, but it is not neces-
sary to understand exactly how these work in order to get the point of the example.

Despite the length of this tutorial, it is only half the story. "Advanced Manipulate Functionality"
provides further information about some of the more sophisticated features of this rich
command.

Manipulate Is as Easy as Table

At its most basic, the syntax of Manipulate is identical to that of the humble function Table.
Consider this Table command, which produces a list of numbers from one to twenty.
Table@n, 8n, 1, 20<D
81, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20<

Simply replace the word Table with the word Manipulate, and you get an interactive applica-
tion that lets you explore values of n with a slider.
 Dynamic Interactivity 45

Manipulate@n, 8n, 1, 20<D

6.18

If you are reading this documentation inside Mathematica, you can click and drag the slider to
see the displayed value change in real time (meaning that it changes while you are dragging
the slider, not just when you release it). If you are reading a static form of the documentation,
you will see the slider moved to an arbitrary position. (By default, it starts out on the left side,
but in the following examples the slider has typically been moved away from its initial position.)

In both Table and Manipulate, the form 8variable, min, max< is used to specify an "iterator",
giving the name of the variable and the range over which to vary it.

Of course the whole point of Manipulate (and Table for that matter) is that you can put any
expression you like in the first argument, not just a simple variable name. Moving the slider in
this very simple output already starts to give an idea of the power of Manipulate.
Manipulate@Plot@Sin@n xD, 8x, 0, 2 Pi<D, 8n, 1, 20<D

1.0

0.5

1 2 3 4 5 6

-0.5

-1.0

Again, if you are reading this in a static form you will have to trust that the graph changes in
real time when the slider is moved.
 46 Dynamic Interactivity

Note that the slider has an extra icon next to it which, when clicked, opens a small panel of
additional controls. Here, the panel from the previous example is opened.

6.42

1.0

0.5

1 2 3 4 5 6

-0.5

-1.0

The panel allows you to see the numerical value of the variable, as well as set it in motion using
the animation controls.

If you want to see the value of the variable without having to open the subpanel, you can add
the option Appearance -> "Labeled" to the variable specification. (Note the number displayed
to the right of the plus sign, which is updated in real time as the slider is moved.)
Manipulate@Plot@Sin@n xD, 8x, 0, 2 Pi<D, 8n, 1, 20, Appearance Ø "Labeled"<D

n 6.1

1.0

0.5

1 2 3 4 5 6

-0.5

-1.0

This is also the first hint that Manipulate goes far beyond the relative simplicity of Table, both
in its output and in the flexibility and range of what can be specified in the list of variables.
 Dynamic Interactivity 47

Just like Table, Manipulate allows you to give more than one variable range specification.

Manipulate@Plot@Sin@n1 xD + Sin@n2 xD, 8x, 0, 2 Pi<, PlotRange Ø 2D,

8n1, 1, 20<, 8n2, 1, 20<D

n1

n2

1 2 3 4 5 6

-1

-2

You can have as many variables as you like, including so many that a similar Table command
would try to enumerate an unreasonably large number of entries.
Manipulate@Plot@a1 Sin@n1 Hx + p1LD + a2 Sin@n2 Hx + p2LD, 8x, 0, 2 Pi<, PlotRange Ø 2D,
8n1, 1, 20<, 8a1, 0, 1<, 8p1, 0, 2 Pi<, 8n2, 1, 20<, 8a2, 0, 1<, 8p2, 0, 2 Pi<D

n1

a1

p1

n2

a2

p2

1 2 3 4 5 6

-1

-2

You can open any or all of the subpanels to see numerical values, and you are free to animate
many different variables at the same time if you like.
 48 Dynamic Interactivity

You can open any or all of the subpanels to see numerical values, and you are free to animate
many different variables at the same time if you like.

One way to think of Manipulate is as a way to interactively explore a large parameter space.
You can move around that space at will, exploring interesting directions as they appear. As you
will see in later sections, Manipulate has many features designed to make such exploration
easier and more rewarding.

Symbolic Output and Step Sizes

The previous examples are graphical, and indeed the most common application for Manipulate
is producing interactive graphics. But Manipulate is capable of making any Mathematica func-
tion interactive, not just graphical ones.

Often the first issue in examples involving symbolic, rather than graphical, output is that you
want to deal with integers, rather than continuously variable real numbers. In Table the default
step size is 1, so you naturally get integers, while in Manipulate the default is to allow continu-
ous variation (which you could think of as a step size of zero). Compare these two examples,
and note that Manipulate allows values in between those returned by Table.
Table@n, 8n, 1, 20<D
81, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20<

Manipulate@n, 8n, 1, 20<D

11.72

Functions involving algebraic manipulations, for example, often do nothing interesting when
given noninteger parameter values. This Expand function never expands anything.

Manipulate@Expand@Ha + bLn D, 8n, 1, 20<D

Ha + bL12.42

Fortunately it is trivial to add an explicit step size of 1 to the Manipulate command, yielding
exactly the same set of possible values in Manipulate as is returned by Table.
 Dynamic Interactivity 49

Fortunately it is trivial to add an explicit step size of 1 to the Manipulate command, yielding
exactly the same set of possible values in Manipulate as is returned by Table.
Manipulate@n, 8n, 1, 20, 1<D

With an explicit step size, the Expand example is much more interesting.

Manipulate@Expand@Ha + bLn D, 8n, 1, 20, 1<D

a10 + 10 a9 b + 45 a8 b2 + 120 a7 b3 + 210 a6 b4 + 252 a5 b5 + 210 a4 b6 + 120 a3 b7 + 45 a2 b8 + 10 a b9 + b10

The fact that only one value is displayed at a time allows you to create examples that go far
beyond what would be practical in a Table command. An important property of Manipulate
output is that there is no fixed panel size or arbitrary limit as to how large the output panel can
grow.

Manipulate@Expand@Ha + bLn D, 8n, 1, 300, 1<D

a53 + 53 a52 b + 1378 a51 b2 + 23 426 a50 b3 + 292 825 a49 b4 + 2 869 685 a48 b5 + 22 957 480 a47 b6 +
154 143 080 a46 b7 + 886 322 710 a45 b8 + 4 431 613 550 a44 b9 + 19 499 099 620 a43 b10 +
76 223 753 060 a42 b11 + 266 783 135 710 a41 b12 + 841 392 966 470 a40 b13 + 2 403 979 904 200 a39 b14 +
6 250 347 750 920 a38 b15 + 14 844 575 908 435 a37 b16 + 32 308 782 859 535 a36 b17 +
64 617 565 719 070 a35 b18 + 119 032 357 903 550 a34 b19 + 202 355 008 436 035 a33 b20 +
317 986 441 828 055 a32 b21 + 462 525 733 568 080 a31 b22 + 623 404 249 591 760 a30 b23 +
779 255 311 989 700 a29 b24 + 903 936 161 908 052 a28 b25 + 973 469 712 824 056 a27 b26 +
973 469 712 824 056 a26 b27 + 903 936 161 908 052 a25 b28 + 779 255 311 989 700 a24 b29 +
623 404 249 591 760 a23 b30 + 462 525 733 568 080 a22 b31 + 317 986 441 828 055 a21 b32 +
202 355 008 436 035 a20 b33 + 119 032 357 903 550 a19 b34 + 64 617 565 719 070 a18 b35 +
32 308 782 859 535 a17 b36 + 14 844 575 908 435 a16 b37 + 6 250 347 750 920 a15 b38 +
2 403 979 904 200 a14 b39 + 841 392 966 470 a13 b40 + 266 783 135 710 a12 b41 + 76 223 753 060 a11 b42 +
19 499 099 620 a10 b43 + 4 431 613 550 a9 b44 + 886 322 710 a8 b45 + 154 143 080 a7 b46 +
22 957 480 a6 b47 + 2 869 685 a5 b48 + 292 825 a4 b49 + 23 426 a3 b50 + 1378 a2 b51 + 53 a b52 + b53
 50 Dynamic Interactivity

(In printed forms of this documentation, the slider is set fairly low to avoid wasting paper, but
when moved all the way to the right, the output smoothly grows to cover many pages worth of
vertical space.)

As with Table, if you use rational numbers for the minimum and step, you will get perfect
rational numbers in the variable, not approximate real numbers. Here is an example that uses
the formatting function Row to create a simple example of adding fractions.
Manipulate@Row@8n, "+", m, "=", n + m<D,
8n, 1 ê 2, 1 ê 3, 1 ê 144<, 8m, 1 ê 2, 1 ê 3, 1 ê 144<D

3 17 61
+ =
8 36 72

You can even use end points and step sizes that are symbolic expressions rather than just plain
numbers.
Manipulate@Row@8n, "+", m, "=", n + m<D, 8n, a, 10 a, a ê 12<, 8m, a, 10 a, a ê 12<D

13 a 11 a
+ =6 a
4 4

Types of Controls
Manipulate supports a wide range of alternate ways of specifying variables, which generate
different kinds of controls for those variables. This includes checkboxes, popup menus, and
others in addition to sliders.
 Dynamic Interactivity 51

The principle is that for each variable, you ask for a particular set of possible values, and
Manipulate automatically chooses an appropriate type of control to make those values conve-
niently available. For a typical numerical Table-like iterator, a slider is the most convenient
interface.

You might, on the other hand, want to specify a discrete list of possible values (numeric or
symbolic) rather than a range. This is done with an iterator of the form
8variable, 8val1, val2, …<<.

(Note the extra level of list compared to the range specification.) If you ask for a small number
of separate values, you will get a row of buttons.
Manipulate@Plot@Sin@n1 xD + Sin@n2 xD, 8x, 0, 2 Pi<, Filling Ø filling, PlotRange Ø 2D,
8n1, 1, 20<, 8n2, 1, 20<, 8filling, 8None, Axis, Top, Bottom<<D

n1

n2

filling None Axis Top Bottom

 52 Dynamic Interactivity

If you ask for a larger number of discrete values, Manipulate will switch to using a popup
menu.
Manipulate@Plot@Sin@n1 xD + Sin@n2 xD, 8x, 0, 2 Pi<, Filling Ø filling, PlotRange Ø 2D,
8n1, 1, 20<, 8n2, 1, 20<,
8filling, 8None, Axis, Top, Bottom, Automatic, 1, 0.5, 0, - 0.5, - 1<<D

n1

n2

filling Automatic

If you use the specific values True and False, you will get a checkbox.

Manipulate@Plot@Sin@n1 xD + Sin@n2 xD, 8x, 0, 2 Pi<, Frame Ø frame, PlotRange Ø 2D,

8n1, 1, 20<, 8n2, 1, 20<, 8frame, 8True, False<<D

n1

n2

frame

-1

-2
0 1 2 3 4 5 6

These choices are of course somewhat arbitrary, but they are designed to be convenient, and
you can always override the automatic choice of control type using a ControlType option
inserted into the variable specification. (The full list of possible control types is given in the
 Dynamic Interactivity 53

These choices are of course somewhat arbitrary, but they are designed to be convenient, and
you can always override the automatic choice of control type using a ControlType option
inserted into the variable specification. (The full list of possible control types is given in the
documentation for Manipulate.)

For example, you can ask for a row of buttons even if the automatic behavior would have
chosen a popup menu, using the option ControlType -> SetterBar.
Manipulate@Plot@Sin@n1 xD + Sin@n2 xD, 8x, 0, 2 Pi<, Filling Ø filling, PlotRange Ø 2D,
8n1, 1, 20<, 8n2, 1, 20<, 8filling,
8None, Axis, Top, Bottom, Automatic, 2, 1, 0, - 1, - 2<, ControlType Ø SetterBar<D

n1

n2

filling None Axis Top Bottom Automatic 2 1 0 -1 -2

 54 Dynamic Interactivity

Sliders can be used to scan through discrete symbolic values, not just through numerical
ranges (and this allows you to animate through them as well). The option
ControlType -> Manipulator asks for the default control used by Manipulate, which is a
slider plus an optional control panel with numerical value and animation controls (see the
previous example). ControlType -> Slider asks for a plain slider.
Manipulate@Plot@Sin@n1 xD + Sin@n2 xD, 8x, 0, 2 Pi<, Filling Ø filling, PlotRange Ø 2D,
8n1, 1, 20<, 8n2, 1, 20<, 8filling, 8None, Axis, Top, Bottom,
Automatic, 1, 0.5, 0, - 0.5, - 1<, ControlType Ø Manipulator<D

n1

n2

filling
 Dynamic Interactivity 55

It is even possible to use two different controls to adjust the value of the same variable. Here
both a popup menu and a slider are connected to the value of the filling variable. If the slider
is used to select a value that does not appear in the popup menu, the popup will appear blank,
but remains functional. When a value is chosen from the popup menu, the slider is moved to
the corresponding position. Both controls can thus be used interchangeably to adjust the same
value, and each one follows along when the other is being used.
Manipulate@Plot@Sin@n1 xD + Sin@n2 xD, 8x, 0, 2 Pi<, Filling Ø filling, PlotRange Ø 2D,
8n1, 1, 20<, 8n2, 1, 20<,
8filling, 8None, 2, 1.5, 1, 0.5, 0, - 0.5, - 1, - 1.5, - 2<<, 8filling, - 2, 2<D

n1

n2

filling 0

filling

This is not an exhaustive list of the possible control types in Manipulate. See the Manipulate
documentation for a more detailed listing. One of the most important control types, Locator,
which allows you to place control points inside graphical output in a Manipulate, is discussed in
"Locator", Slider2D is discussed in the "2D Sliders" section.
 56 Dynamic Interactivity

Initial Values and Labels

Here is a fun example for making Lissajous figures.

Manipulate@ParametricPlot@8a1 Sin@n1 Hx + p1LD, a2 Cos@n2 Hx + p2LD<,

8x, 0, 20 Pi<, PlotRange Ø 1, PerformanceGoal Ø "Quality"D,
8n1, 1, 4<, 8a1, 0, 1<, 8p1, 0, 2 Pi<,
8n2, 1, 4<, 8a2, 0, 1<, 8p2, 0, 2 Pi<D

n1

a1

p1

n2

a2

p2

1.0

0.5

-1.0 -0.5 0.5 1.0

-0.5

-1.0

Unfortunately you see nothing at first: until you move the a1 and a2 (amplitude) variables away
from their initial values of zero, there is nothing to see. It would be convenient to set their
initial value to something other than the default left-most value. This is done by using a vari-
able specification of the form 88var, init<, min, max<.
 Dynamic Interactivity 57

Here is the same example with both amplitudes set to 1 initially, and the default frequency
values set to give a pleasing initial figure.
Manipulate@ParametricPlot@8a1 Sin@n1 Hx + p1LD, a2 Cos@n2 Hx + p2LD<,
8x, 0, 20 Pi<, PlotRange Ø 1, PerformanceGoal Ø "Quality"D,
8n1, 1, 4<, 88a1, 1<, 0, 1<, 8p1, 0, 2 Pi<,
88n2, 5 ê 4<, 1, 4<, 88a2, 1<, 0, 1<, 8p2, 0, 2 Pi<D

n1

a1

p1

n2

a2

p2

1.0

0.5

-1.0 -0.5 0.5 1.0

-0.5

-1.0
 58 Dynamic Interactivity

It is fun to watch how one shape turns into another, and in this connection it is good to know
about an unusual feature of sliders in Mathematica. If you hold down the Option key
(Macintosh) or Alt key (Windows), the action of the slider will be slowed down by a factor of 20
relative to the movements of the mouse. In other words, when you drag the mouse left and
right, the thumb will move only 1/20th as much as it normally would. If you move outside the
area of the slider, the value will start moving slowly in that direction as long as the mouse
remains clicked.

By holding down the Shift or Ctrl keys, or both, in addition to the Option/Alt key, you can slow
the movement down by additional factors of 20 (one for each additional modifier key). With all
three held down, it is possible to move the thumb by less that one part per million of its full
range, which can be helpful in examples like this where beautiful patterns are hidden in very
small ranges of parameter space.

(The option PerformanceGoal -> "Quality" is used in this example to ensure that
ParametricPlot draws smooth curves even when a slider is being moved: the need for this
option is explained in more detail in "Advanced Manipulate Functionality".)

By default Manipulate uses the names of the variables to label each control. But you may want
to provide longer, more descriptive labels, which can be done by using variable specifications of
the form 88var, init, label<, min, max<.

Here is the same example with labels.

 Dynamic Interactivity 59

Manipulate@ParametricPlot@8a1 Sin@n1 Hx + p1LD, a2 Cos@n2 Hx + p2LD<,

8x, 0, 20 Pi<, PlotRange Ø 1, PerformanceGoal Ø "Quality"D,
88n1, 1, "Frequency 1"<, 1, 4<, 88a1, 1, "Amplitude 1"<, 0, 1<,
88p1, 0, "Phase 1"<, 0, 2 Pi<, 88n2, 5 ê 4, "Frequency 2"<, 1, 4<,
88a2, 1, "Amplitude 2"<, 0, 1<, 88p2, 0, "Phase 2"<, 0, 2 Pi<D

Frequency 1

Amplitude 1

Phase 1

Frequency 2

Amplitude 2

Phase 2

1.0

0.5

-1.0 -0.5 0.5 1.0

-0.5

-1.0

Beautifying the Control Area

Manipulate supports a number of features that allow you to rearrange, annotate, and generally
pretty up the control area, to make it suit the needs of a particular example. (Advanced users
should remember, however, that Manipulate is by no means the only way to create interactive
interfaces in Mathematica, and if you cannot do what you want using Manipulate, you can
easily start using functions such as Dynamic and DynamicModule directly to create free-form,
open-ended user interfaces not tied to the particular conventions of Manipulate. These fea-
tures are explained in detail in "Introduction to Dynamic" and "Advanced Dynamic Functional-
ity".)

When you have a small number of controls, it is usually most convenient to have them above
the content area of the Manipulate panel. But because screens are typically wider than they
are tall, if you have a large number of controls, you may find it better to put them on the left
 60 Dynamic Interactivity

When you have a small number of controls, it is usually most convenient to have them above
the content area of the Manipulate panel. But because screens are typically wider than they
are tall, if you have a large number of controls, you may find it better to put them on the left
side, using the ControlPlacement option.
Manipulate@ParametricPlot@8a1 Sin@n1 Hx + p1LD, a2 Cos@n2 Hx + p2LD<, 8x, 0, 20 Pi<,
PlotRange Ø 1, PerformanceGoal Ø "Quality"D, 88n1, 1, "Frequency 1"<, 1, 4<,
88a1, 1, "Amplitude 1"<, 0, 1<, 88p1, 0, "Phase 1"<, 0, 2 Pi<,
88n2, 5 ê 4, "Frequency 2"<, 1, 4<, 88a2, 1, "Amplitude 2"<, 0, 1<,
88p2, 0, "Phase 2"<, 0, 2 Pi<, ControlPlacement Ø LeftD

Frequency 1 1.0

Amplitude 1

Phase 1
0.5
Frequency 2

Amplitude 2

Phase 2
-1.0 -0.5 0.5 1.0

-0.5

-1.0

When ControlPlacement is used at the level of the Manipulate as a whole, it sets the default
position of all the controls. But the option can also be used inside individual variable specifica-
tions, allowing you to distribute controls to multiple sides of the output field.

In the following example the controls naturally fall into two groups of three, or three groups of
two. You can use the keyword Delimiter inserted in the sequence of variable specifications to
indicate where you would like dividing lines put. Here two unlabeled delimiters break the con-
trols up into three groups.
 Dynamic Interactivity 61

Manipulate@ParametricPlot@8a1 Sin@n1 Hx + p1LD, a2 Cos@n2 Hx + p2LD<,

8x, 0, 20 Pi<, PlotRange Ø 1, PerformanceGoal Ø "Quality"D,
88n1, 1, "Frequency 1"<, 1, 4<, 88n2, 5 ê 4, "Frequency 2"<, 1, 4<,
Delimiter, 88a1, 1, "Amplitude 1"<, 0, 1<, 88a2, 1, "Amplitude 2"<, 0, 1<,
Delimiter, 88p1, 0, "Phase 1"<, 0, 2 Pi<,
88p2, 0, "Phase 2"<, 0, 2 Pi<, ControlPlacement Ø LeftD

Frequency 1 1.0

Frequency 2

Amplitude 1 0.5

Amplitude 2

Phase 1
-1.0 -0.5 0.5 1.0

Phase 2

-0.5

-1.0

Alternately strings, or delimiters and strings, can be used to label the groups of controls.
 62 Dynamic Interactivity

Manipulate@ParametricPlot@8a1 Sin@n1 Hx + p1LD, a2 Cos@n2 Hx + p2LD<,

8x, 0, 20 Pi<, PlotRange Ø 1, PerformanceGoal Ø "Quality"D,
"Horizontal", 88n1, 1, "Frequency"<, 1, 4<,
88a1, 1, "Amplitude"<, 0, 1<, 88p1, 0, "Phase"<, 0, 2 Pi<,
Delimiter, "Vertical", 88n2, 5 ê 4, "Frequency"<, 1, 4<,
88a2, 1, "Amplitude"<, 0, 1<, 88p2, 0, "Phase"<, 0, 2 Pi<, ControlPlacement Ø LeftD

Horizontal
1.0
Frequency

Amplitude

Phase 0.5

Vertical

Frequency

Amplitude -1.0 -0.5 0.5 1.0

Phase

-0.5

-1.0

Quite a variety of things can be interspersed with the controls, including styled text, arbitrary
expressions, and even dynamic objects that update independently of the main output window.
Here is a simple example of using Style to make the group headings more prominent.
 Dynamic Interactivity 63

Manipulate@ParametricPlot@8a1 Sin@n1 Hx + p1LD, a2 Cos@n2 Hx + p2LD<,

8x, 0, 20 Pi<, PlotRange Ø 1, PerformanceGoal Ø "Quality"D,
Style@"Horizontal", 12, BoldD, 88n1, 1, "Frequency"<, 1, 4<,
88a1, 1, "Amplitude"<, 0, 1<, 88p1, 0, "Phase"<, 0, 2 Pi<,
Delimiter, Style@"Vertical", 12, BoldD, 88n2, 5 ê 4, "Frequency"<, 1, 4<,
88a2, 1, "Amplitude"<, 0, 1<, 88p2, 0, "Phase"<, 0, 2 Pi<, ControlPlacement Ø LeftD

Horizontal
1.0
Frequency

Amplitude

Phase 0.5

Vertical
Frequency

-1.0 -0.5 0.5 1.0

Amplitude

Phase

-0.5

-1.0

Examples of more complex arrangements and dynamic labels are shown in "Advanced Manipu-
late Functionality".

2D Sliders
A clever feature of Mathematica is support for two-dimensional sliders, which allow you to use
both directions of mouse movement to control two values simultaneously. (Ordinary one-
dimensional sliders in a sense waste one of the two degrees of freedom a mouse is capable of.)

To get a 2D slider, use pairs of numbers for both the min and max, as in
8var, 8xmin , ymin <, 8xmax , ymax <<
 64 Dynamic Interactivity

The value of the variable will also be an 8x, y< pair. In this trivial example, just look at the
value of the variable to get a feel for how the control works.
Manipulate@pt, 8pt, 8- 1, - 1<, 81, 1<<D

pt

8-0.19, 0.33<

The following example shows more graphically how the value of a 2D slider corresponds to a
coordinate point.
Manipulate@Graphics@8PointSize@0.1D, Point@ptD<, PlotRange Ø 1D,
8pt, 8- 1, - 1<, 81, 1<<D

pt
 Dynamic Interactivity 65

To do something more interesting, you can recast the Lissajous figure from the previous section
with three 2D sliders instead of six 1D sliders. You are controlling the same six parameters, but
now you can do it two at a time.
Manipulate@
ParametricPlot@8a@@1DD Sin@n@@1DD Hx + p@@1DDLD, a@@2DD Cos@n@@2DD Hx + p@@2DDLD<,
8x, 0, 20 Pi<, PlotRange Ø 1, PerformanceGoal Ø "Quality"D,
88n, 81, 5 ê 4<, "Frequency"<, 81, 1<, 84, 4<<,
88a, 81, 1<, "Amplitude"<, 80, 0<, 81, 1<<,
88p, 80, 0<, "Phase"<, 80, 0<, 82 Pi, 2 Pi<<, ControlPlacement Ø LeftD

1.0

Frequency

0.5

Amplitude

-1.0 -0.5 0.5 1.0

Phase

-0.5

-1.0

This creates an example that is compact and fun. Note that fine control using the Option, Shift,
and Ctrl keys to slow down the motion of sliders (as explained in "Initial Values and Labels")
works for 2D sliders as well as 1D sliders.
 66 Dynamic Interactivity

Graphics beyond Plotting

So far high-level plotting functions have mostly been used, but it is equally interesting to use
Mathematica's low level graphics language inside Manipulate. The following example, repeated
from the previous section, is a trivial example of using the low-level graphics language.
Manipulate@Graphics@8PointSize@0.1D, Point@ptD<, PlotRange Ø 1D,
8pt, 8- 1, - 1<, 81, 1<<D

pt

This example also makes the important point that anytime you use Graphics inside
Manipulate, you probably want to set an explicit PlotRange option. (PlotRange -> 1 means 1
in all directions from the origin, and is equivalent to PlotRange -> 88- 1, 1<, 8- 1, 1<<.) If you
omit the PlotRange option Mathematica's automatic plot range determination will cause the dot
to appear not to move at all, because the plot range is always exactly centered around it.
 Dynamic Interactivity 67

Simple (or complicated) Mathematica programming can add arbitrary graphical elements to the
output. For example, here we have lines to the center point instead of a dot, with a second
linear slider determining the number of lines.
Manipulate@
Graphics@8Line@Table@88Cos@tD, Sin@tD<, pt<, 8t, 2. Pi ê n, 2. Pi, 2. Pi ê n<DD<,
PlotRange Ø 1D, 88n, 30<, 1, 200, 1<, 8pt, 8- 1, - 1<, 81, 1<<D

pt
 68 Dynamic Interactivity

Here is a fun little string-figure example also based on creating a table of lines.

Manipulate@
Graphics@Line@Table@88Sin@n + iD, Cos@n + iD<, 8Sin@n + dn + iD, Cos@n + dn + iD<<,
8i, 0, di, di ê l<DD, PlotRange Ø 1.1D, 8n, 0, 2 p<,
8dn, 0, 2 p<, 8di, 1, 2 p<, 8l, 1, 200<, ControlPlacement Ø LeftD

dn

di

Because Mathematica is a sophisticated programming language, it is possible to use

Manipulate to explore parameterized programs or algorithms interactively. The Mathematica
graphics language is explained in "The Structure of Graphics", and many more examples like
this can be found in The Wolfram Demonstrations Project.

Locator
For creating interactive graphics examples, one of the most important features of Manipulate
is the ability to place a control point, called a Locator, inside graphics that appear in the output
area.
 Dynamic Interactivity 69

Consider the previous example with lines going to a center point. While using a 2D slider is a
fine way to control the center point, you might prefer to be able to simply click and drag the
center point itself. This can be done by adding Locator to the control specification for the pt
variable. In this case it is not necessary to specify a min and max range, because it can be taken
automatically from the graphic. (It is, however, necessary to specify an initial value.)
Manipulate@
Graphics@8Line@Table@88Cos@tD, Sin@tD<, pt<, 8t, 2. Pi ê n, 2. Pi, 2. Pi ê n<DD<,
PlotRange Ø 1D, 88n, 30<, 1, 200, 1<, 88pt, 80, 0<<, Locator<D

Now you can click anywhere in the graphic and the center point of the lines will follow the
mouse as long as you keep the mouse button down. (It is not necessary to click exactly on the
center; it will jump to wherever you click, anywhere in the graphic.)

You can have multiple Locator controls by listing them individually, and it is perfectly fine to
have a Manipulate with no controls outside the content area, so you can create purely graphi-
cal examples.
 70 Dynamic Interactivity

Manipulate@Graphics@Polygon@8pt1, pt2, pt3<D, PlotRange Ø 1D,

88pt1, 80, 0<<, Locator<, 88pt2, 80, 1<<, Locator<, 88pt3, 81, 0<<, Locator<D

When there are multiple locators, you can still click anywhere in the graphic, and the nearest
Locator will jump to where you click and start tracking the mouse.

Instead of using multiple separate variables, each of which corresponds to a single 8x, y< point,
you can use a single variable whose value is a list of points.
 Dynamic Interactivity 71

Manipulate@Graphics@Polygon@ptsD, PlotRange Ø 1D,

88pts, 880, 0<, 81, 0<, 80, 1<<<, Locator<D

Again, if you click anywhere in the graphic, not on a particular Locator, the nearest one will
jump to the mouse and start tracking it.

Due to internal limitations, it is not possible to combine individual Locator variables with a
variable that is a list of multiple Locator variables: you can have only one multipoint Locator
variable in a Manipulate. However, in exchange, it is possible to add the option
LocatorAutoCreate -> True to that one Locator multivariable specification, and thereby allow
you to create and destroy Locator points interactively (changing the length of the list of points
stored in the variable).

In the following example, hold down the Cmd key (Macintosh) or Alt key (Windows) and click
anywhere that is not an existing Locator to create a new one at that location. Cmd/Alt click an
existing Locator to destroy it. When you add or remove a Locator, you are changing the
length of the list of points stored in the pts variable, thus changing the number of vertices in the
displayed polygon.
 72 Dynamic Interactivity

Manipulate@Graphics@Polygon@ptsD, PlotRange Ø 1D,

88pts, 880, 0<, 8.5, 0<, 80, .5<<<, Locator, LocatorAutoCreate Ø True<D

You can of course combine Locator controls with normal Manipulate variables. For example,
you can use some sliders and color choosers to control the appearance of the polygon.
 Dynamic Interactivity 73

Manipulate@
Graphics@8FaceForm@faceD, EdgeForm@8edge, Thickness@thicknessD<D, Polygon@ptsD<,
PlotRange Ø 1, Background Ø backgroundD,
8face, Green<,
8edge, Red<,
8background, Cyan<,
88thickness, 0.02<, 0, 0.1<,
88pts, 880, 0<, 8.5, 0<, 80, .5<<<, Locator, LocatorAutoCreate Ø True<D

face

edge

background

thickness

While a case can be made that the previous examples are frivolous, they are meant to demon-
strate the generality of the system: it provides a framework inside of which anything is possi-
ble. And the following example shows that even just a couple of lines of code can do something
quite remarkable: create an interactive polynomial curve-fitting environment.

The locator thumbs represent data points that are being fit by least squares with a polynomial
whose order is determined by the "order" slider. Five points are provided initially, but you can
add new ones by Cmd/Alt clicking any blank area of the graphic, or remove one by Cmd/Alt
clicking it.
 74 Dynamic Interactivity

Manipulate@Module@8x<, Plot@Fit@points, Table@x ^ i, 8i, 0, order<D, xD,

8x, - 2, 2<, PlotRange Ø 2, ImageSize Ø 500, Evaluated -> TrueDD,
88order, 3<, 1, 10, 1, Appearance Ø "Labeled"<,
88points, RandomReal@8- 2, 2<, 85, 2<D<, Locator, LocatorAutoCreate Ø True<D

order 3

-2 -1 1 2

-1

-2

The fact that an example of this sophistication can be constructed using such a small volume of
code is really quite remarkable. And if you want to really impress someone with the compact-
ness of Mathematica code, the following example shows how to do it using only two lines, with
some loss of generality. Practice a bit and you can type this from scratch in 30 seconds or less.
Manipulate@Plot@InterpolatingPolynomial@points, xD, 8x, - 2, 2<, PlotRange Ø 2D,
88points, RandomReal@8- 2, 2<, 85, 2<D<, Locator<D

-2 -1 1 2

-1

-2

3D Graphics
 Dynamic Interactivity 75

3D Graphics
Manipulate can be used to explore 3D graphics just as easily as 2D, though performance
issues become more of a concern. Consider this simple example.
Manipulate@Plot3D@Sin@n x yD, 8x, 0, 3<, 8y, 0, 3<D, 8n, 1, 5<D

For large values of n the function oscillates rapidly, and in order to produce a smooth picture,
the default adaptive sampling algorithm in Plot3D produces a fairly large number of polygons,
with correspondingly long computation and rendering times.

Fortunately, Plot3D and other built-in plotting functions automatically adjust their internal
algorithms and settings when used inside Manipulate in order to deliver increased speed while
a control is being dragged, sometimes at the expense of rendering quality. As soon as the
mouse button is released, a high-quality version of the plot is generated asynchronously
(meaning other operations in the front end can continue while the plot is being generated).
Asynchronous evaluations are discussed in further detail in "Synchronous Versus Asynchronous
Dynamic Evaluations" in "Advanced Dynamic Functionality".
 76 Dynamic Interactivity

The net result is that while you drag the slider, a fast, but somewhat crude, rendering of the
plot is created in real time, and when you release the control, a smooth rendering shows up a
moment later. (This happens because Plot3D, and most other plotting functions, refer to the
function ControlActive in the default settings of the various options that control rendering
quality and speed. See "Dealing with Slow Evaluations" in "Advanced Manipulate Functionality"
for more about using ControlActive within Manipulate.)

As in 2D, you can use the low-level graphics language just as easily as higher-level plotting
commands. In this example you can see how Mathematica handles spheres that intersect with
each other and with the bounding box.
Manipulate@Graphics3D@8Sphere@80, 0, 0<, r1D, Sphere@8c@@1DD, c@@2DD, 0<, r2D<,
PlotRange Ø 2D, 88r1, 1<, 0, 2<, 88r2, 1<, 0, 2<, 8c, 8- 2, - 2<, 82, 2<<D

r1

r2

c
 Dynamic Interactivity 77

This example shows how opacity (which is to say, transparency) can be used to see inside
nested 3D structures.
Manipulate@SphericalPlot3D@ q + f, 8q, 0, a p<, 8f, 0, b p<, SphericalRegion Ø True,
PlotRange Ø 10, Ticks Ø None, BaseStyle Ø Opacity@opacityDD,
8a, 0.1, 2<, 8b, 0.1, 2<, 8opacity, 1, 0<D

opacity

(Note that adding transparency to a 3D graphic can slow down rendering significantly.)

You can rotate a 3D graphic inside a Manipulate output by clicking and dragging it in the
ordinary way. In most cases if you subsequently move one of the Manipulate controls, the
graphic will stay rotated to the position you moved it to manually, unless the graphics expres-
sion in the Manipulate contains an explicit ViewPoint option, or wraps the graphical output in
additional formatting constructs.
 78 Dynamic Interactivity

All Types of Output Are Supported

Manipulate is designed to work with the full range of possible types of output you can get with
Mathematica, and it does not stop with graphical and algebraic output. Any kind of output
supported by Mathematica can be used inside Manipulate. Here are some examples which may
be less than obvious.

Formatting constructs such as Grid, Column, Panel, etc. can be used to produce nicely format-
ted outputs. (See "Grids, Rows, and Columns" for more information about formatting
constructs.)
Manipulate@Grid@Table@8i, i ^ m<, 8i, 1, n<D, Alignment Ø Left, Frame Ø AllD,
8n, 1, 20, 1<, 8m, 1, 100, 1<D

1 1
2 17 179 869 184
3 16 677 181 699 666 569
4 295 147 905 179 352 825 856
5 582 076 609 134 674 072 265 625
6 286 511 799 958 070 431 838 109 696
7 54 116 956 037 952 111 668 959 660 849

You can even wrap Manipulate around functions that generate user interface elements like
sliders and tab views. (See "Control Objects" and "Viewers and Annotation" for more informa-
tion about user interface elements.) In this example we use two sliders to control the appear-
ance of a third slider.
Manipulate@Column@88style, size<, Slider@0.5, Appearance Ø 8style, size<D<D,
8style, 8"Automatic", "Vertical", "LeftArrow",
"RightArrow", "UpArrow", "DownArrow"<, ControlType Ø Slider<,
8size, 8"Automatic", "Tiny", "Small", "Medium", "Large"<, ControlType Ø Slider<D

style

size

8UpArrow, Tiny<

In this more complicated example the structure of a TabView is controlled by a Manipulate.

Dynamic@paneD allows the current pane of the TabView to be selected either by using the slider
 Dynamic Interactivity 79

In this more complicated example the structure of a TabView is controlled by a Manipulate.

Dynamic@paneD allows the current pane of the TabView to be selected either by using the slider
created by Manipulate, or by clicking the TabView in the output area. The output is fully active.

1
ManipulateBTabViewBTableBNestB &, base, iF, 8i, 1, n<F,
1-Ò
Dynamic@paneD, Alignment Ø alignmentF,
8n, 1, 20, 1<, 8alignment, 8- 1, - 1<, 81, 1<<, 8pane, 1, n, 1<F

alignment

pane

1 2 3 4 5 6 7 8 9

1
1
1- 1
1- 1
1-
1
1-
1-base

This example may be somewhat alarming, but is meant only to illustrate that Manipulate is a
fully general function, not limited to exploring any fixed domain of graphical or algebraic exam-
ples. There is literally nothing you can see in a cell in a Mathematica notebook that you cannot
interactively explore using Manipulate (subject only, of course, to the speed of your computer).