Mathematica Not Interpreting Free Parameters Correctly

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 -> #[[1]], b -> #[[2]]} & /@ 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[#[[2]]] & /@ 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[#[[2]]] == 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[[1]]; 
    best[[2]] /. Thread[best[[3]] -> vars]]

    In[30]:= expr1 = ((-1)^(2/3) - (-1)^(1/3) a + a b)/(e1 (-(-1)^(1/3) + a + (-1)^(2/3) a b));
    VOISimplify[{a, b, e1}, expr1, None]

    Out[31]= -((-1)^(1/3)/e1)

    In[32]:= expr2 = ((-1)^(2/3) - (-1)^(1/3) z + z b)/(e1 (-(-1)^(1/3) + z + (-1)^(2/3) z b));
    VOISimplify[{b, z, e1}, expr2, None]

    Out[33]= -((-1)^(1/3)/e1)

""