# Assiging Plot Range to Variables Works For X but Not Theta

Observe the following Mathematica code:

g1[x_, t_] := Tan[x]*Sin[2 Pi t] + Cot[x]*Cos[2 Pi t];
rs1 := {x, -1.5 \[Pi], 1.5 \[Pi]};
rx1 := {-1.5 \[Pi], 1.5 \[Pi]};
ry1 := rx1;

Animate[Plot[g1[x, t], rs1, PlotRange -> {rx1, ry1}, Axes -> False,
AspectRatio -> Automatic, PlotStyle -> Thickness[0.01]], {t, 0, 1},
RefreshRate -> 60, AnimationDirection -> Forward,
DefaultDuration -> 7]

g3[\[Theta]_, t_] := ArcTan[Sin[2 Pi t + 3 \[Theta]] Sin[3 \[Theta]]];
rs3 := {\[Theta], 0, 2 \[Pi]};
rx3 := {-1, 1};
ry3 := rx3;

Animate[PolarPlot[g3[\[Theta], t], rs3, PlotRange -> {rx3, ry3},
Axes -> False, AspectRatio -> Automatic,
PlotStyle -> Thickness[0.01]], {t, 0, 1}, RefreshRate -> 60,
AnimationDirection -> Forward, DefaultDuration -> 7]


This is able to successfully plot g1, but it fails to plot g3, stating that "Range specification rs3 is not of the form {x,xmin,xmax}." But I don't understand why it is expecting x when I am using theta. What am I doing wrong? How do I make this work correctly so that it can plot the polar graph g3?

Example screenshot: https://i.stack.imgur.com/oluK9.png

• Try Evaluate@rs3 instead of rs3. Apr 8, 2021 at 3:08
• @MichaelE2, thank you, that solved it, but can you explain why it is necessary when using theta but not necessary when using x? To me this just feels arbitrary. Apr 8, 2021 at 3:24
• It's not theta vs x. It's PolarPlot vs. Plot. Plot inspects the value of the argument (apparently) if it does not have the right form, which is the case: rs1 is a symbol, not a list, and therefore Plot inspects it. PolarPlot apparently does not and complains instead of inspecting the value of rs3. You might complain to WRI support about the inconsistency. Neither choice is perfect, for technical reasons I don't have time to go into. Probably it was one way, and then they changed Plot but not PolarPlot. Or vice versa. Apr 8, 2021 at 3:49

The issue is not θ vs x. It's PolarPlot vs. Plot. They both have the HoldAll attribute. This is to prevent a value that the variable, either θ or x, might have outside the plot call from replacing the symbolic variable. While the plot functions both have the HoldAll attribute, they do different things with their arguments. This is undocumented, and one can only observe their behaviors. Plot inspects the value of the (second) argument (apparently) if the argument does not have the right form, namely, a list: rs1 as a held argument is a symbol, not a list, and therefore Plot inspects it. It evaluates to a list of the correct form, and Plot is happy. PolarPlot apparently does not inspect the symbol rs3 and complains instead that it is not a list of the correct form. IMO, they should have the same behavior. But they don’t and that’s how it is.

The following fixes the problem if θ doesn't have a value:

g3[θ_, t_] :=
ArcTan[Sin[2 Pi t + 3 θ] Sin[3 θ]];
rs3 := {θ, 0, 2 π};
rx3 := {-1, 1};
ry3 := rx3;

Clear[θ];
Animate[PolarPlot[g3[θ, t],
Evaluate@rs3,
PlotRange -> {rx3, ry3}, Axes -> False, AspectRatio -> Automatic,
PlotStyle -> Thickness[0.01]], {t, 0, 1}, RefreshRate -> 60,
AnimationDirection -> Forward, DefaultDuration -> 7]


In both Plot and PolarPlot, this approach will fail is the variable if x or θ have a numerical value (respectively).

Here's a quick example how to shoot down the first Animate/Plot example and make the second Animate/PolarPlot bullet-proof:

x = 10; (* this is the bullet *)
Animate[Plot[g1[x, t], rs1, PlotRange -> {rx1, ry1}, Axes -> False,
AspectRatio -> Automatic, PlotStyle -> Thickness[0.01]], {t, 0, 1},
RefreshRate -> 60, AnimationDirection -> Forward,
DefaultDuration -> 7]

(* \$Failed *)


This bullet-proofing works on Plot, too:

θ = 3;  (* the bullet *)
Animate[
Hold[                 (* READY: the kevlar *)
g3[θ, t], rs3, PlotRange -> {rx3, ry3}, Axes -> False,
AspectRatio -> Automatic, PlotStyle -> Thickness[0.01]
] /.
OwnValues[rs3] /.   (* SET: slip the value under the kevlar *)
Hold -> PolarPlot,  (* GO! *)
{t, 0, 1}, RefreshRate -> 60,
AnimationDirection -> Forward, DefaultDuration -> 7]


This rather roundabout approach doesn't allow θ to be evaluated, unlike the Evaluate@rs3.