possible improvements

[Christian Bauer]

Hi!

On Wed, Jul 31, 2002 at 01:47:45PM +0200, Chris Dams wrote:
> (3) Using so-called schoonschip-notation for indexed objects.
> [...]
> Example: A.mu~nu*p~mu --> A(p,~nu)

I'd rather call this "invariant notation". Well, it would be truly invariant
if it was written like A(p,e), where 'e' is an object representing a base...

The reason why GiNaC uses a purely indexed notation is that Feynman rules
are given with explicit indices and when constructing expressions for graphs,
the indices would need to appear anyway. Also, we often need to refer to
specific components of indexed expressions.

While it is true that the proposed "mixed" notation would eliminate most
(all?) dummy indices (which is desirable), I'm not sure whether this would
blend in seamlessly with the current notation. Some issues that come to my
mind:

1) One must be careful not to lose information about the dimensionality
   of the dummy indices. We have cases where an expression like A.i.j*p~j
   could appear with j=0..3 or with j=0..D-1 (D>=4), and where this makes
   a difference. In the current notation, this is easily expressed with
   the dummy index dimensions (this is the "subspace" feature of GiNaC
   1.0.10). One could argue that the four-dimensional 'A' or 'p' are really
   different objects from the D-dimensional ones but using the index
   dimensions for this frees one from having to introduce new classes
   representing tensors projected into subspaces. The same holds true for
   inner products (i.e. k.i(4)*l~i(4) different from k.i(D)*l~i(D);
   GiNaC 1.1 will soon be updated to allow scalar_products to make that
   distinction).

2) There are spaces in which A.i.j*p~j != A.i~j*p.j (e.g. when i,j are
   spinidx). How would this be handled in the proposed notation?
   (Granted, GiNaC also assumes that it can reposition dummy indices
   unless they are spinidx, which I'm not completely happy with. Maybe
   the idx class should take a new flag that indicates whether this is
   possible or not.)

3) What if, for example, you have A.i.j*q~i*p~j where A.i.j is a complex-
   valued symmetric tensor and the components of p and q are Grassmann
   quantities? If you write this as A(q,p) it might give the impression
   that by the symmetry of A, this would be equal to A(p,q), which it isn't.
   How would you represent the difference between A.i.j*p~j and p~j*A.i.j
   if the components of A and p do not commute?

> Also one would want to introduce the notion of an inner product, leading
> to the automatic simplification rule: p.mu*q~mu --> inp(p,q).

I don't see how this could be done in the automatic evaluator (within the
given complexity constraints). simplify_indexed() can do this transformation
for you if you add your own class to represent inner products.

> Also one no longer needs to call simplify_indexed, [...]

I do not think so. If I get an expression of the form c1*A.i.j from place
A and multiply it with an expression like c2*p~j obtained from place B,
I would need to call something similar to simplify_indexed to have this
transformed to c1*c2*A.p.i, so there's not much improvement here.

> (4) Haven't really looked at this terribly carefully yet, but I suppose
> the function dirac_trace can be made much more efficient.

I'd be happy to integrate any patches. :-)

> The idea of expanding gamma5 into eps(i1,i2,i3,i4)*gamma(i1)*...*gamma(i4)
> (which happens inside the function dirac_trace)

Although that's the general formula (from hep-ph/9401354, Eq.(18)), also
mentioned in the source, that's not exactly what happens in dirac_trace(),
at least not in that blunt way. E.g. if you pass a string of gamma5 and
6 other gammas to dirac_trace(), it will not start taking traces of
10-gamma strings and contracting the four dummy indices, but rather loop
over all permutations of the existing 6 indices, taking only sub-traces of
2-gamma strings (which evaluate trivially in trace_string()). I do not
think there's a more efficient way for the case of arbitrary indices (and
within dimensional regularization).

Bye,
Christian

-- 
  / Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/