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/