CommuteCovDs (multiple times)
Leo Stein
I have found that sometimes when doing GR calculations, one needs to
commute several covariant derivatives, and this becomes cumbersome
since CommuteCovDs accepts only one pair of indices; this leads to
expressions such as
CommuteCovDs[
CommuteCovDs[
CommuteCovDs[expr, CD, {a, b} ], CD, {b, c}], CD, {c, a}]
for example. One way around this is to use Fold:
Fold[ CommuteCovDs[#1, CD, #2]&, expr, {{a,b}, {b,c}, {c,a}} ]
I humbly propose that this be integrated into CommuteCovDs, along the
lines of:
CommuteCovDs[ expr_, covd_, rest__ ] := Fold[ CommuteCovDs[#1, covd,
#2] & , expr, {rest} ]
which would allow one to simply write:
CommuteCovDs[ expr, CD, {a, b}, {b, c}, {c, a} ]
Please consider my humble feature request.
Cheers
Leo
JMM
Thank you for your suggestion of generalizing CommuteCovDs to high-
order derivatives, which I find very reasonable. I'm not so sure about
the notation to use, so let us discuss it.
First, I see CommuteCovDs as the controlled version of SortCovDs. The
function SortCovDs is able to sort any number of covd abstract indices
lexicographically, and CommuteCovDs allows you to reorder a specific
pair. I see your point that CommuteCovDs should also allow sorting any
number of indices in any specific order. That means we need to give
the indices we want to reorder and the final order in which we want to
have them. Hence the natural notation for that is a permutation.
Your notation {{a,b},{b,c},{c,a}} is essentially a decomposition of a
permutation into transpositions (it is always possible to decompose a
permutation into a product of transpositions). That is not easy to
read. In particular if you have many transpositions it is difficult to
predict what the final order of indices will be. Perhaps a notation
like {b,a,c}->{c,a,b} would be clearer to specify what we want to do.
It is true that we know the Ricci identity only for pairs, and so the
algorithm must actually decompose the permutation into transpositions,
trying to find the decomposition with the minimal number of
transpositions, and therefore your notation must also be present, at
least internally.
What do you think?
Cheers,
Jose.
Leo Stein
JMM
You are right that the decomposition of a permutation as a "word" in a
given set of generators is a nontrivial problem. But fortunately this
is not what we need here. We need a decomposition into transpositions.
This is almost trivial: you convert the permutation into cyclic form
and from there it is very simple to construct the transpositions. I
can handle that easily and fast. Using the Ricci identity with many
indices will take much more time than the group-theoretical part.
What I'd like to discuss is what is the best extended notation for
CommuteCovDs. In other words, what is that you want to do but cannot
do with SortCovDs? In my experience SortCovDs is more useful than
CommuteCovDs for canonicalization, so I guess is not for
canonicalization that you'd like to have this extension.
Thanks again,
Jose.
On Mar 16, 3:41 pm, Leo Stein <leo.st...@gmail.com> wrote:
> I see your point!
> Unfortunately, this is deeper into algorithms and group theory than I know.
> I know that a factorisation into generators exists, but I thought that
> finding this factorisation was "hard" in the same sense that factoring
> integers under multiplication was hard. Algorithms certainly exist (e.g.http://www.gap-system.org/Manuals/doc/htm/ref/CHAP037.htm#SECT005) but it
> seems they may be slow if there are many indices to permute. In practice, I
> can't imagine there being more than five or six indices, which is a pretty
> small number, so a naive algorithm might do just fine, but won't scale.
> However, I must recuse myself here since I am not an expert in factoring
> group elements.
>
> Cheers
> Leo
>
Leo Stein
JMM
> Actually, I did not know about SortCovDs. I was trying to automate checking
> of gauge invariance of some quantities, which involves performing an
> infinitesimal gauge transformation and then commuting various derivatives to
> get as many terms to cancel as possible (and then being left with terms
> which hopefully cancel from Bianchi identities). SortCovDs turns out to do
> this well, so my manual commutations are not necessary.
Good. This is what I expected. Indeed SortCovDs is more frequently
used than CommuteCovDs, even though the latter allows more control in
the computation. SortCovDs is a canonicalizer. It is not automatically
implemented in ToCanonical because we always want to control by hand
at which point of the calculation the bunch of Riemann tensors must
appear.
> Is the group theory part really so simple? Only adjacent derivative
> operators may be commuted -- so if one has a term such as
> CD[b]@CD[a]@CD[c]@T[...] and one wishes to end up with a term like
> CD[c]@CD[a]@CD[b]@T[...], one can not "apply the transposition (bc)",
> because the only admissible transpositions are (ab) and (ac).
This is true. I was thinking that it should be possible to generalize
the standard Ricci identity to cope with that, so that the number of
transposition to do is linear in the number of indices. If you don't
want to do that, or if it is difficult to generalize the Ricci
identity to non-contiguous indices then the number of adjacent
transpositions grows quadratically in the number of indices, which is
not that bad either. If you want to go from the indices {a3,a7,...,a2}
to {a1,...,a7} then take a1 in the first list and move it one by one
to its final leftmost position. Then take a2 in the resulting list and
move it to the left, etc. You see that the worst case is reversing
{an,...,a1} to {a1,...,an}, which requires n(n-1)/2 adjacent
transpositions.
> Actually, the cycle notation doesn't seem to be the same as what CommuteCovDs does. (ac)
> and (ca) represent the same group element, but CommuteCovDs[expr,CD,{a,c}]
> does something different than CommuteCovDs[expr,CD,{c,a}]. Maybe I am
> missing something. Can you explain how this should work?
It is true that those two calls of CommuteCovDs have different
meaning, but they are never simultaneously possible, because the
difference refers to the current position of indices. The notation is
not very clear, and that is why I was interested in finding something
better.
Cheers,
Jose.