One difficulty in using Manipulate
is that it rewrites your code for you in ways that are not clearly explained in the documentation. The thinking is that this rewriting achieves the dynamic interactions described in the documentation without burdening the programmer with some of the tedious details involved. For instance, expressions that contain Manipulate
variables get wrapped in Dynamic
, so that they will be updated when the variable changes. This allows controls to interact with each other. But exactly how and when code is rewritten is not clearly explained.
The documentation somewhat vaguely suggests that a variable/control declaration of the form
{var, a, b}
should be equivalent to
{{var, a}, a, b}
For instance, from tutorial/IntroductionToManipulate
:
It would be convenient to set their initial value to something other than the default left-most value. This is done by using a variable specification of the form {{var, init}, min, max}
.
In the OP's case, the declaration
{ang, x, 2}
should be written
({ang, x}, Dynamic[x], 2}
and result in a control
Manipulator[Dynamic[ang], {Dynamic[x], 2}]
placed in the Manipulate
output when shown in the Front End, with ang
initialized to x
. This is what m_goldberg and Kuba were referring to in their answer and comment respectively.
In fact what seems to happen is that the rewrite results in
{ang, Dynamic[x], 2}
which is equivalent, by the default initialization rule, to
{{ang, Dynamic[x]}, Dynamic[x], 2}
which also explains what Kuba observed.
In my opinion, this behavior is avoidable and should be considered a bug. However, WRI developers might disagree with me.
Note that we do not run into this problem with the example from the tutorial cited by the OP. The declaration
{m, 1, n, 1}
is rewritten
{m, 1, Dynamic[n], 1}
-- is equivalent to
{{m, 1}, 1, Dynamic[n], 1}
-- and results in the control
Manipulator[Dynamic[m], {1, Dynamic[n], 1}]
in the output with m
initialized to 1
. Since it is not initialized to Dynamic[n]
, we do not see the same problem as in the OP's code.
A workaround, as m_goldberg already pointed out, is to initialize ang
explicitly.