What the first part of the variable declaration does
Manipulate initializes complexparts to {Re[#], Im[#]} & when it executes. (In general, a declaration of the form {{var, expr},...} in a Manipulate results in the local variable var being initialized to expr.) To use complexparts outside of the Manipulate, do this:
complexparts = {Re[#], Im[#]} &;
With[{θ = 0.25, b = 0.5 + 0.2 I},
complexparts /@ {E^(I π θ), b E^(-I π θ),
E^(I π θ) + b E^(-I π θ), 0}]
(* {{0.707107, 0.707107}, {0.494975, -0.212132}, {1.20208, 0.494975}, {0, 0}} *)
Addendum 1 -- What "None" does
To illustrate @Mr.Wizard's remark about Initialization, one could modify @David's code above as follows:
Manipulate[
complexparts[E^(I Pi t)],
{{t, 1/4.}, 0., 2},
{complexparts, None},
Initialization :> (complexparts = {Re[#], Im[#]} &)
]
The declaration {complexparts, None} declares complexparts to be a local variable of the DynamicModule that is created by the Manipulate command. Whether complexparts needs to be declared local or not doesn't seem important in such an example. Generally I try to localize variables whenever possible, especially in Manipulate, as it saves headaches if you're doing scratch work in the same kernel that the Manipulate uses. Since the intended scope of complexparts is entire body of the Manipulate (and furthermore, it never changes), declaring it as a variable in a Manipulate seems appropriate. It hardly matters here, but in some cases it can make a big difference.
Update -- Reference to the manual
I have found a passage in the manual which I believe documents the usage of None. There are two alternatives for specifying a control type
{u, ..., ControlType -> type}
or more briefly
(u, ..., type}
This last one is not described but is used frequently in the examples. Technically it has the form
{u, ..., func}
where func is a function that constructs the control; however, since None is not a function, one can object that None must be treated as a special case. On the other hand, the reference page state
Possible control types include: Animator.... None can also be used.
The effect of a variable declaration is described thus:
Manipulate generates a DynamicModule object, with the variables u, v, etc. specified as local.
While the manual does not clearly state that {u,..., None} is accepted usage, it does state that what is practically equivalent, {u,..., ControlType -> None} is:
Use ControlType to specify the type of control to use, including None:
Manipulate[u, {u, 0, 1}, ControlType -> None]
Addendum 2 -- "None" and other alternatives
In response to the updated title for @David's question, as well as to some of the comments, the following might be worth studying to see the differences.
Problem. We need the variable var to be local. It takes a long time to compute its value. It won't change its value, but we need to dynamically access the value (or parts of the value).
As an example, var is to be a list of squares and the "long time" is simulated by Pause[0.2]. We wish to display part n of var with the slider for n. The solutions below all do the "same" thing. But there are differences in how each works. Depending on what one is trying to do, the differences can be significant. In my opinion, #1 is the best; the others can be fine in appropriate situations. I'll explain below.
(* 1 *)
Manipulate[
var[[n]],
{n, 1, 10, 1},
{{var, Table[Pause[0.2]; n^2, {n, 10}]}, None}
]
(* 2 *)
Manipulate[
var[[n]],
{n, 1, 10, 1},
{var, None},
Initialization :> (var = Table[Pause[0.2]; n^2, {n, 10}])
]
(* 3 *)
Module[{var = Table[Pause[0.2]; n^2, {n, 10}]},
Manipulate[
var[[n]],
{n, 1, 10, 1}
]
]
(* 4 *)
Manipulate[
Module[{var = Table[Pause[0.2]; n^2, {n, 10}]},
var[[n]]],
{n, 1, 10, 1}
]
The most important thing to ask is when is var calculated in each solution above:
Once when the input cell is first evaluated.
Every time the Manipulate output is (re)activated. For instance, every time the notebook is opened.
Once when the input cell is first evaluated. (Same as #1.)
Every time n changes value. This is terrible.
The second question is where is var stored:
In the output cell (in the notebook) and loaded into the kernel. Can make a very big notebook file, but the data is persistent.
In the output cell l (in the notebook) as in 1 (and overwritten by the Initialization code). Correction due to @unlikely.
Just in the kernel, when the input cell is evaluated. (Note the difference in #1.)
In the kernel, after recalculation.
Next, does the output work when the notebook is reopened? Will it work as a CDF? As a Wolfram Demonstration? (Each has the same answer for a given solution):
1, 2, 4: Yes.
3: No. (Even if var were made global, a Demonstration must have Manipulate as the outside function.)
So in summary,
Fast, fast on re-open of notebook, quick start-up in a CDF.
Fast, slow on re-open, slow start-up in a CDF. (Change pause to 5 seconds, and you'll see a problem.)
Fast, won't work on reopen, won't work in a CDF.
Super slow all the time.
Now what's going on?
In #1, the data is computed first and fed to Manipulate, which stores in the output. That's what happens in {{var, initial_value},..}.
In #2, the Initialization code is stored unevaluated in the output. Every time the output cell is activated (by opening the notebook and scrolling to the cell), the Initialization code is evaluated.
In #3, a local variable is first created in the kernel and initialized; the local id for var is stored in the Manipulate output. When the notebook is reopened, this id is invalid. You have to reevaluate the input again to get it to work.
In #4, a new local variable is created every time the Manipulate is updated (on start-up and every time a control is moved or a tracked variable changes); the variable is then initialized, so this can cost a lot a time. When the initialization time is short, you won't really notice the difference between #1, #2, and #4.
