# What is and isn't a valid variable specification for Manipulate?

I have an expression whose terms have arguments (representing subscripts), like this:

myExpr = A + V[1,T]


I would like to put it inside a Manipulate to see its value as I move around the parameters. (The goal is eventually to plot it wrt one of the variables inside.)

However, Mathematica complains when I set V[1,T] as a manipulated variable:

Manipulate[Evaluate[myExpr], {A, 0, 1}, {V[1, T], 0, 1}]
(*Manipulate::vsform: Manipulate argument {V[1,T],0,1} does not have the correct form for a variable specification. >> *)


As a workaround, if I get rid of the symbol T inside the argument, it works fine:

Manipulate[
Evaluate[myExpr /. T -> 15], {A, 0, 1}, {V[1, 15], 0, 1}]


Why this behavior? Can anyone point me to the documentation that says what counts as a valid variable? And is there a way to get Manpiulate to accept an expression with a symbolic argument as a variable?

Investigations I've done so far:

• I tried using variableQ from this answer, but it says V[1,T] is fine as a valid variable.
• And Plot works just fine with V[1,T] as the variable, as in:

Plot[myExpr /. A -> 2, {V[{1, T}], 1, 2}]

I suspect it's an internal decision by WRI to allow as variables only expressions of the form A[0, 1, 2], that is, a symbol with integer arguments. You could try reporting your desired functionality to WRI; maybe they will extend what expressions are allowed. Instead of being localized in the usual way, the expressions are remapped to Unique[] symbols. For instance, the expression A would be mapped to a symbol like $101. In this scheme, almost any expression could be allowed as a variable, because it can be replaced by a valid variable name. One danger is that in an expression like V[1, T], the symbol T would not be localized, so if T changed value, one should expect a change in behavior. One could wish that V[0, T] were mapped to $102, but that would remove the dependency on T. From a programming point of view, this would be really bad. But if T in a user's program is an inert symbol, then from the user's point of view, it is a bit irritating not to be able to do it.

Well, with some hacking, you could do it like you want, but let me first suggest this:

Manipulate[{A, V1T}, {A, 0, 1}, {{V1T, 0, HoldForm@V[1, T]}, 0, 1}] Hack:

The check on what is a valid variable is performed ManipulateDumpextendedVariable. You can add your own allowed forms like this:

InternalInheritedBlock[{ManipulateDumpextendedVariable},
ManipulateDumpextendedVariable[_Symbol[__]] := True;
Manipulate[{A, V[1, T]}, {A, 0, 1}, {V[1, T], 0, 1}]
] This would be a little safer, but I would still recommend the first approach above:

InternalInheritedBlock[{ManipulateDumpextendedVariable},
ManipulateDumpextendedVariable[_Symbol[(_Integer | _String) ..]] := True;
Manipulate[{A, V[1, "T"]}, {A, 0, 1}, {V[1, "T"], 0, 1}]
]


Bug/Restriction (updated):

My point seemed to be lost in the simple example I originally gave, so I have changed it and added some explanation to try to clarify the issues. My claim was and is: I'm not sure why forms like A are allowed. They don't work the way they do in normal Mathematica.

The point is that when expressions A etc. are replaced by Unique[] symbols like $123, only the literal expressions like A etc. are replaced in the Manipulate code by kernel, before the Manipulate is sent back to the front end for instantiation. An expression like A[n] that evaluates to A at runtime will not be linked to the actual variable $123 being used to represent A.

Manipulate[{A, A[n]}, {A, 0, 1}, {n, 0, 1, 1}] // InputForm
(*
Manipulate[{$3340, A[n]}, (*$*)
{{$3340, 0, RawBoxes[RowBox[{"A", "[", "0", "]"}]]}, 0, 1}, (*$*)
{n, 0, 1, 1}]
*) A more complicated example, which might illustrate better a more practical use of A[n], is given below. But simplicity has advantages in an issue that is complicated and potentially confusing.

One reason for using variables like A, A, etc. is to be able to parametrize them by A[n]. Such functionality can often be accomplished with lists, which can be made to work in Manipulate, but that seems a separate issue. Workarounds are not an explanation. My point is that one of the basic uses of A etc. cannot be implemented in Manipulate.

A more complicated example:

Manipulate[
With[{f = Sum[A[n] x^n, {n, 0, m}]},
Plot[f, {x, -1, 1}, PlotLabel -> f]
],
{A, 0, 1}, {A, 0, 1}, {A, 0, 1},
{m, 0, 2, 1}] Note that A, A, and A in the list are not updated or connected to the controls. (This is because, while A is remapped to $nnn, the expression A[n] is not!) My advice is to avoid them, and use {{A0, 0, HoldForm@A}, 0, 1}  instead. A workaround for the last example, for those who like them: Manipulate[ With[{f = Sum[A[n] x^n, {n, 0, m}] /. {A[n_] /; n == 0 :> A, A[n_] /; n == 1 :> A, A[n_] /; n == 2 :> A}}, Plot[f, {x, -1, 1}, PlotLabel -> f] ], {A, 0, 1}, {A, 0, 1}, {A, 0, 1}, {m, 0, 2, 1}] The literal occurrences of A, A and A in the replacement rules are replaced by unique $nnn in the kernel:

{A[n_] /; n == 0 :> A, A[n_] /; n == 1 :> A, A[n_] /; n == 2 :> A}}


At runtime the rules replace the evaluated A[n] by the corresponding $nnn variable. Such a set of rules has to be applied at all appropriate places in the code. For instance it cannot be applied to the whole body, because it has to be applied to f before Plot is evaluated. In a complicated piece of code, it would be a big pain. In such an application, it would be best to avoid them. After all, that is basically what Manipulate is doing already by rewriting them as simple variables (original example): Manipulate[ Table[A[n], {n, 3}], {A, 0, 1}, {A, 0, 1}, {A, 0, 1}] // InputForm (* Manipulate[Table[A[n], {n, 3}], {{$3335, 0, RawBoxes[RowBox[{"A", "[", "1", "]"}]]}, 0, 1},
{{$3336, 0, RawBoxes[RowBox[{"A", "[", "2", "]"}]]}, 0, 1}, {{$3337, 0, RawBoxes[RowBox[{"A", "[", "3", "]"}]]}, 0, 1}]
*)

• Michael, your example with a Table of A[n] seems like it's about evaluation order more than things like A being allowed. It works fine with Evaluate: Manipulate[Evaluate[Table[A[n], {n, 3}]], {A, 0, 1}, {A, 0, 1}, {A, 0, 1}]. While this fails in the same way, unless there is an evaluate: listOfVars = {x, y, z}; Manipulate[(*Evaluate@*) listOfVars, {x, 0, 1}, {y, 0, 1}, {z, 0, 1}]
– Seth
Feb 18 '16 at 3:47
• @Seth, And what if the number of terms depended on another Manipulate parameter, e.g. Sum[A[n], {n, m}]? Plus, you can hardly program an arbitrary Manipulate under the assumption that the body will be evaluated before the variables are localized. Your second example seems quite a different situation, since it depends on a global variable, unlike the Table command. Feb 18 '16 at 4:00
• @Seth, If you want a more complete example, consider Manipulate[Plot[Sum[A[n] x^n, {n, 0, m}], {x, -1, 1}], {A, 0, 1}, {A, 0, 1}, {A, 0, 1}, {m, 0, 2, 1}]. -- And here's a fix based on my analysis: Manipulate[Plot[Sum[A[n] x^n, {n, 0, m}] /. {A[n_] /; n == 0 :> A, A[n_] /; n == 1 :> A, A[n_] /; n == 2 :> A}, {x, -1, 1}], {A, 0, 1}, {A, 0, 1}, {A, 0, 1}, {m, 0, 2, 1}] Feb 18 '16 at 4:06
• You almost certainly already know this, but I think it should be mentioned that a work-around for your Table example is: Manipulate[Evaluate @ Table[A[n], {n, 3}], {A, 0, 1}, {A, 0, 1}, {A, 0, 1}] Feb 18 '16 at 6:00
• @MichaelE2, here's a version of my listOfVars example without a global variable: Manipulate[ Evaluate@(ToExpression /@ Table[letter, {letter, {"x", "y", "z"}}] ) , {x, 0, 1}, {y, 0, 1}, {z, 0, 1}] . Again, Evaluate does the trick, making the symbols x, y, z visible to Manipulate.
– Seth
Feb 18 '16 at 8:22