# Mathematica Not Interpreting Free Parameters Correctly

Forgive me if this has an obvious answer, but I've run into seemingly the same problem in a few different contexts now. When I evaluate expressions using different variables, all of which show up as blue (unused), I sometimes get different results. For example,

((-1)^(2/3) - (-1)^(1/3) a + a b)/(e1 (-(-1)^(1/3) + a + (-1)^(2/3) a b)) // FullSimplify


-(Power[-1, (3)^-1]/e1)

((-1)^(2/3) - (-1)^(1/3) z + z b)/(e1 (-(-1)^(1/3) + z + (-1)^(2/3) z b)) // FullSimplify


((b-Power[-1, (3)^-1]) z+(-1)^(2/3))/(e1 ((-1)^(2/3) b z+z-Power[-1, (3)^-1]))

where the only difference in these two lines is changing a to z. Neither a nor z appears in my notebook otherwise, and both have color formatting indicating that they're representing something else, and yet I get two entirely different expressions (the lower one is what I expect). Is there some reason why Mathematica doesn't like the variable a for writing expressions? And is there some documentation on what kind of variables would lead to this issue so I don't accidentally run into it in the future? Thanks for any insight!

• Even direct replacement /. z -> a in the second equation results in this. Definitely strange. Tried it in 9.0, 10.1, and 11.2 with the same results. Aug 29 '18 at 22:20
• I suggest that this is not incorrect as much as surprising. Mathematica does not give you a wrong answer in either case. I think you will find it comes down to sorting order. I guess any letter after b will behave the same. Aug 29 '18 at 22:30
• @Mikado is right, the non-canonical results are due to vagaries of internal sorting of variables, which inturn is affected by naming of variables. One can come closer to achieving a canonical result using Together and allowing an algebraic extension, e.g. In:= Together[((-1)^(2/3) - (-1)^(1/3) z + z b)/(e1 (-(-1)^(1/3) + z + (-1)^(2/3) z b)), Extension -> Automatic] Out= 1/((-1 + (-1)^(1/3)) e1) Aug 29 '18 at 23:31
• Thanks all for the help! I suppose I'll just have to be more careful about my variable choices. As eyorble suggested, I reported the problem to Wolfram Support. Aug 30 '18 at 13:59
• Aug 30 '18 at 14:30

This is a partial answer that provides some insight into the specific variable names this applies to in this problem. This is a brute force of the common, non-reserved, single letter names.

Store these variables as a list, varsA:

varsA = {a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w,
x, y, z, A, B, F, G, H, J, L, M, P, Q, R, S, T, U, V, W, X, Y, Z};


Find all 2-variable combinations of this list:

varsAA = Tuples[varsA, 2];


Construct all replacement rules for {a -> X, b -> Y}, where X and Y are an {X, Y} pair from varsAA.

rulesAA = {a -> #[], b -> #[]} & /@ varsAA;


Define the expression to be tested in held form:

expr = Hold[((-1)^(2/3) - (-1)^(1/3) a +  a b)/(e1 (-(-1)^(1/3) + a + (-1)^(2/3) a b))];


Then find all replacements of a and b in this expression. Since FullSimplify is used here, this will probably take a while.

results = {#, FullSimplify[ReleaseHold[expr] /. #]} & /@ rulesAA;


We store the original rule in the first member of this list so that we can refer to it later.

We use LeafCount to check which of these expressions are simplified:

Tally[LeafCount[#[]] & /@ results]


{{10, 49}, {40, 1938}, {41, 38}}

Most of the expressions do not simplify, these are the 1938 expressions which have a LeafCount of 40. A handful of expressions actually become longer: it turns out that these are expressions where a and b are replaced with the same variable (so long as it isn't a, b, c, d, e, A, or B), so a square appears in the unsimplified form. The remaining expressions are greatly simplified to a LeafCount of 10.

Let's look at the replacements that led to those specific expressions:

Select[results, LeafCount[#[]] == 10 &][[1 ;; -1, 1]]

{{a -> a, b -> a}, {a -> a, b -> b}, {a -> a, b -> c},
{a -> a, b -> d}, {a -> a, b -> e}, {a -> a, b -> A},
{a -> a, b -> B}, {a -> b, b -> a}, {a -> b, b -> b},
{a -> b, b -> c}, {a -> b, b -> d}, {a -> b, b -> e},
{a -> b, b -> A}, {a -> b, b -> B}, {a -> c, b -> a},
{a -> c, b -> b}, {a -> c, b -> c}, {a -> c, b -> d},
{a -> c, b -> e}, {a -> c, b -> A}, {a -> c, b -> B},
{a -> d, b -> a}, {a -> d, b -> b}, {a -> d, b -> c},
{a -> d, b -> d}, {a -> d, b -> e}, {a -> d, b -> A},
{a -> d, b -> B}, {a -> e, b -> a}, {a -> e, b -> b},
{a -> e, b -> c}, {a -> e, b -> d}, {a -> e, b -> e},
{a -> e, b -> A}, {a -> e, b -> B}, {a -> A, b -> a},
{a -> A, b -> b}, {a -> A, b -> c}, {a -> A, b -> d},
{a -> A, b -> e}, {a -> A, b -> A}, {a -> A, b -> B},
{a -> B, b -> a}, {a -> B, b -> b}, {a -> B, b -> c},
{a -> B, b -> d}, {a -> B, b -> e}, {a -> B, b -> A},
{a -> B, b -> B}}


One hypothesis here is that @mikado's comment is on the mark: the simplification is being affected by the variable sorting. However, it is not the sorting of a and b that matters so much as the sorting between either a or b as compared to e1. You can test your original expression replacing b with z and e1 with zz, and it will simplify to the short form.

At a quick glance, the short form does appear to be correct at least. As far as workarounds go, aside from applying intuition or randomly shuffling variable names occasionally, I'm afraid I don't have any suggestions. I'd personally expect FullSimplify to try to be as unaffected by the internal sorting of the variables as possible, but it's understandable that there may occasionally be issues. I'd recommend reporting this to Wolfram support.

For what it's worth, here's the response I got back from Wolfram Support:

"" As I understand you have an inquiry about a certain FullSimplify[] behavior.

Our developers are aware of the behavior and the same is documented as well: ref/FullSimplify#33243688 (paste the string in Documentation and hit enter)

FullSimplify[] applies transformation rules to simplify expressions and variable sorting is a necessary step for certain transformations. In one of the developer's words:

"Some transformations used by FullSimplify (like reduction mod equation assumptions, or collecting terms wrt. variables) require specifying an order of variables. To make sure the results are variable name independent one would need to try all permutations."

While they are considering alleviating the limitation in future (if you have any ideas on how to achieve the same, please feel free to let us know), they gave the following workaround (based on all permutations) for now:

    VOISimplify[vars_, expr_, assum_: True] :=
Module[{perm, ee, best}, perm = Permutations[vars];
ee = (FullSimplify @@ ({expr, assum} /. Thread[vars -> #1]) &) /@ perm; best = Sort[{LeafCount /@ ee, ee, perm} // Transpose[];