# Strange Manipulate behavior

Running the following code and pressing the play button under b will input -2147483648 in b.

Manipulate[
a = 2,

{{a, 1}, ControlType -> None},
{{b, 1}, 1, a, 1, Appearance -> "Open"}]


I believe this occurs only when all of these are true:

• A variable is the max value of another variable.
• Both variables have the initial value of 1.
• The variable with the max value of the other variable has a step size.
• The variable with the max value of the other variable has the option Appearance -> "Open".
• Part is used (but there are exceptions)

An exception, I found that the code works only when the value put in a is 1, thus not changing the value (e.g. a = {3, 2, 1}[[3]], a = 1).

Curiously, when the initial value of a or b is set to anything other than 1, when the Appearance is not "Open", or when the step size is removed, the code runs flawlessly.

I think this is a bug, but it needs to be verified by other users.

\$Version

(* "10.1.0  for Microsoft Windows (64-bit) (March 24, 2015)" *)
(* "10.3.1 for Microsoft Windows (64-bit) (December 9, 2015)" *)


Edit: Part seems not to be required for this to occur.

• I can confirm that behavior on MMA 10.4.0 Win7-64. It only happens if I hit play right after evaluating the expression; Instead, if I first move the slider manually, then hit play, it works fine. Although I'll admit that I don't understand your Manipulate construct. Although I can't exactly pinpoint my unease with it, it seems to me that it would set up some unpleasant race conditions when updating variable values. When would such a construct occur? – MarcoB Jun 23 '16 at 15:52
• @MarcoB It's odd that moving the slider first doesn't create the issue. On Mathematica 10.3.1 and 10.1.0, the same issue occurs even after moving the slider. – JungHwan Min Jun 23 '16 at 16:08
• @MarcoB I have a memoized function in Initialization that outputs a list of polygons. The length of this list changes when the input changes. The input is another slider that I did not include in my code (since that's unrelated to the issue). I needed that the max value of my slider for frame (in this case, a) change according to the output. This is causing the issue. – JungHwan Min Jun 23 '16 at 16:36

Although syntactically correct, your Manipulate expression is somewhat strange. Normally, one does not initialize a control in the first argument of a Manipulate expression, but I know of nothing in the literature of dynamic constructs that forbids it.

On the other hand, because the order in which control variables are initialized is not clearly documented and sometimes appears to be very strange, I have come to be cautious about such initialization.

To see some of the strangeness, let us consider two variants of your code.

DynamicModule[{a = 3},
Manipulate[Row[{a = 2, "  ", b}],
{{b, 1}, 1, a, 1, Appearance -> "Open"}]]


In this case the assignment made in 1st argument of the dynamic module sets the upper limit of control b. The assignment made in the 1st argument of the Manipulate seems to ignored or overridden in setting the upper limit of b. Now I will add a control specification for a within the Manipulate expression. If it has any effect, it should constrain the upper limit of b to 1, right?

DynamicModule[{a = 3},
Manipulate[Row[{a = 2, "  ", b}],
{{a, 1}, ControlType -> None},
{{b, 1}, 1, a, 1, Appearance -> "Open"}]]


Adding the control specification for a did have a effect, but not the one I predicted. Now the 1st argument of Manipulate expression is setting the upper limited of b Why? I don't know. However, it does have the merit of working the you expected you code to.

To get the same effect without the DynamicModule wrapper, you can write

Manipulate[Row[{a = 2, "  ", b}],
{a, ControlType -> None},
{{b, 1}, 1, a, 1, Appearance -> "Open"},
Initialization :> (a = 3)]


It has the same behavior as the 2nd example above, and is the work-around I recommend. The value assigned to a doesn't have to be 3, of course. Any value the would be acceptable as the upper limit element of b will do, which makes me think that this value becomes the upper limit of b briefly during initialization, but gets overridden further along in the process.

• I could not think of a better code construct that would alter the upper bound of a variable according to the output of a function. Altering a variable of a Manipulate inside a function declared in Initialization sometimes causes problems when saving and opening the manipulate/entire notebook. – JungHwan Min Jun 24 '16 at 4:59
• @JHM. It appears that your actual problem is quite a bit more complex than the toy problem you posted here. I suggest you ask a new question with an example that better describes your real issues. I can see no way of discussing further complications within the framework of this toy problem. – m_goldberg Jun 24 '16 at 5:17

This doesn't answer the question of "why does this bug out" but this answer is a DynamicModule that is equivalent to your Manipulate that you could add your Initialization function to.

DynamicModule[
{a = 2, b = 1},
Panel[
Column[{
Manipulator[Dynamic[b], {1, a, 1}, Appearance -> "Open"],
Framed[Dynamic[a], Background -> White,
ImageSize -> {500, 100}]}]
]
]


• I need this to be Manipulate because I am submitting my project to Wolfram Demonstrations. – JungHwan Min Jun 23 '16 at 21:05
• Ah - I see. Well last time I asked they're looking to move Demonstrations onto the Cloud and might use the opportunity to extend their rules to allow DynamicModules. But I already admitted I didn't answer the question this time :) – Charlie Joey Hadley Jun 23 '16 at 21:08
• An alternative would be not to use "Open" and press the + to open the controls. – JungHwan Min Jun 23 '16 at 21:09