# Why is TensorContract[x, {}] not always x?

If I use TensorTranspose on an undefined symbol, nothing happens unless the permutation is the identity. For instance, TensorTranpose[x, {1,2,3}] gives x, but TensorTranspose[x, {2, 1, 3}] remains unevaluated. This seems like good behavior.

I would likewise expect TensorContract to remain unevaluated, unless the second argument is an empty list (no contractions) in which case it should do nothing. However, TensorContract[TensorTranspose[x, {2, 1, 3}], {}] strangely gives TensorTranspose[x, {2, 1}].

Stranger still, the outcome depends on the permutation in TensorTranspose; in the rank-3 case, this only happens with {2, 1, 3}. For rank-4, the unexpected cases are:

{2, 1, 3, 4}    TensorTranspose[x, {2, 1}]
{3, 1, 2, 4}    TensorTranspose[x, {3, 1, 2}]
{3, 2, 1, 4}    TensorTranspose[x, {3, 2, 1}]


It seems like, for whatever reason, it likes chopping off tails of these permutations that coincide with the identity. Is this a bug? And what might be the underlying issue?

• This is not a bug. We can see it as a canonicalization step. TensorTranspose only needs to know the slots that change, so it ignores information regarding the slots that do not change. Effectively, this is behavior inherited from the internal use of Cycles notation, which also ignores slots that do not change.
– jose
Nov 15, 2022 at 18:01
• Great to know, thanks. Now that I know what I'm looking for, I see it in the documentation for TensorTranspose: one of the examples under Properies & Relations is TensorTranspose[array, {2, 1}] == TensorTranspose[array, {2, 1, 3}] which evaluates to True. Nov 15, 2022 at 20:02