Symbol ordering and commutation properties

A conventional way to sort factors in a product is to use lexographical ordering. However, this is almost never what one wants when transcribing a physics problem to the computer. Therefore, Cadabra allows you to specify the sort order of symbols yourself. This is done by associating the SortOrder list property to a list of symbols, as in

{X,G,Y,A,B}::SortOrder. ex:= A*B*G*X*A*X: sort_product(_);

$\displaystyle{}X X G A A B$

X X G A A B

More complicated objects with indices are of course also allowed, such as in

{ W_{m n}, W_{m} }::SortOrder; ex:= W_{m n} W_{p} W_{q r} W_{s} W_{t}: sort_product(_);

$\displaystyle{}\text{Property SortOrder attached to }\left[W_{m n}, W_{m}\right].$

$\displaystyle{}W_{m n} W_{q r} W_{p} W_{s} W_{t}$

W_{m n} W_{q r} W_{p} W_{s} W_{t}

It is not allowed to have more than one such set contain the same symbol. Thus,

{X,G}::SortOrder; {X,A,B}::SortOrder;

$\displaystyle{}\text{Property SortOrder attached to }\left[X, G\right].$

$\displaystyle{}\text{Property SortOrder attached to }\left[X, A, B\right].$

is not allowed (and will, in fact, take $X$ out of the first list).

ex:= A*B*G*X: sort_product(_);

$\displaystyle{}X G A B$

X G A B

Apart from the preferred sort order, there are more properties which influence the way in which products can be sorted. In particular, sort order is influenced by whether symbols commute or anti-commute with each other. Physicists in general use a very implicit notation as far as commutativity of objects in a product is concerned. Consider for instance a situation in which we deal with two operators $\hat M$ and $\hat N$, as well as some constants $q$ and $p$. These two expressions are equivalent: \begin{equation} 2q\, \hat M p \hat N \quad\text{and}\quad 2pq\, \hat M \hat N \,. \end{equation} But this is not obvious from the notation that has been used to indicate the product. In fact, the product symbol is usually left out completely.

In many other computer algebra systems, you have to introduce special types of "non-commuting" products (e.g. the &* operator in Maple or the ** operator in Mathematica). This can be rather cumbersome, for a variety of reasons. The main reason, however, is that it does not match with what you do on paper. On paper, you never write special product symbols for objects which do not commute. You just string them together, and know from the properties of the symbols whether objects can be moved through each other or not.

In order to make these sort of things possible in Cadabra, it is necessary to declare "sets" of objects which mutually do not commute (i.e. for which the order inside a product cannot be changed without consequences) but which commute with objects of other sets. Many computer algebra systems only use one such set: objects are either "commuting" or "non-commuting". This is often too restrictive. For instance, when $\Psi$ is a fermion and $\Gamma$ denotes a Clifford algebra element, a system with only one set of non-commuting objects is unable to see that \begin{equation} \bar\Psi_a (\Gamma_n\Gamma_m)_{ab} \Psi_b \quad\text{and}\quad \bar\Psi_a \Psi_b (\Gamma_n\Gamma_m)_{ab} \end{equation} are equivalent. In Cadabra one would simply put $\Psi_{a}$ and $\Gamma_{m}$ in two different sets, mutually commuting, but non-commuting among themselves. To be precise, the example above is reproduced by

\bar{#}::Accent; \Psi_{a}::SelfNonCommuting; \Gamma_{#}::GammaMatrix; ex:= \bar{\Psi_a} (\Gamma_n \Gamma_m)_{ab} \Psi_b; sort_product(_);

$\displaystyle{}\text{Property Accent attached to }\backslash\texttt{bar}\{\#\}.$

$\displaystyle{}\text{Property SelfNonCommuting attached to }\Psi_{a}.$

$\displaystyle{}\text{Property GammaMatrix attached to }\backslash\texttt{Gamma}\{\#\}.$

$\displaystyle{}\bar{\Psi_{a}} \left(\Gamma_{n} \Gamma_{m}\right)\,_{ab} \Psi_{b}$

\bar{\Psi_{a}} \indexbracket(\Gamma_{n} \Gamma_{m})_{ab} \Psi_{b}

$\displaystyle{}\bar{\Psi_{a}} \Psi_{b} \left(\Gamma_{n} \Gamma_{m}\right)\,_{ab}$

\bar{\Psi_{a}} \Psi_{b} \indexbracket(\Gamma_{n} \Gamma_{m})_{ab}

Commutation properties always refer to components. If you associate an ImplicitIndex property to an object, then it will never commute with itself or with any other such object. You can see this in the example above, as the prodsort command kept the order of the two gamma matrices unchanged.