[GiNaC-devel] Matrices vs indexed [Was: Fixes w.r.t. indexed objects]

[Chris Dams]

Dear all,

As far as I know there are no operations in GiNaC that work for indexed
objects in general dimensions but no longer if one imagines that they
really are the standard tensors of finite dimension that everybody knows
and loves. Because of this I do not see any problem with allowing users to
interpret indexed expressions either way. We are not the Coq-project where
the meaning of everything has to be defined and nailed down.

Also, at the moment there is code in GiNaC to expand indexed expressions
as in a.i[2]*b.i[2] -> a.1*b.1 + a.2*b.2. I even have to admit that I
myself recently patched that code in CVS the 1.4 and have the intention to
backport it to 1.3. I don't think that there is anything wrong with that
kind of code. One simply shouldn't call it if one wants to do dimensional
regularization.

What I do have doubts about is giving varidxes to matrices. After all, if
the varidxes are numeric the matrix that carries them will evaluate to the
same matrix element no matter whether they are up or down. This is clearly
strange and it begs the question what a varidx given to a matrix is useful
for anyway. So, I would not object to the idea of forbidding giving
varidxes to matrices.

As for Vladimirs Q5 in ginac-list, I think it is just fine to use idxes in
this case. The Einstein summation convention is very much meaningful in
GiNaC, however, all index renaming code that I have written and/or patched
assumes the restrictions that I mentioned before. If one wants to use
A~mu*A.mu withous summing over mu, I suggest one defines a symbolic
function nosum and uses A~nosum(mu)*A.nosum(mu). If one wants A.i*B.i*C.i
with summing over indices, then Vladimirs idea of "labels" in combination
with some class to be able to write something like sum(j, 0, n,
A_j*B_j*C_j) should probably be useful.

Best wishes,
Chris