[GiNaC-list] Simplifying indexed expressions not
alejandrolimache at hotmail.com
Fri Jul 28 00:11:57 CEST 2006
>(1) What if the indices are of different dimension? Should it be possible
>to specify a different dimension for every index postion? IMO, this would
>get a bit overly complicated. Maybe user-defined inner products should
>only be used if all dimensions of indices involved are the same. This, at
>least, seems to cover your case.
The cases of inner products of physical quantities that I can recall
always involve indices of the same dimension, but maybe
in some general optimization or minimization problems
one might have different dimensions.
These inner products usually measure some kind of energy or power.
In the case of FEM (Finite Element Method) there are times where
you can get products M.k.i.j*A.i.j of multidimensional arrays M,A where
for example i and j have dimension of space (3) and k the dimension of the
of nodes or elements. However in this case there is no contraction of the k
>(2) What if T happens to be symmetric and D is not? Then the product
>T.i.j*D.i.j might automatically evaluate into T.j.i*D.i.j and the
>contraction would no longer occur, depending on what the canonical
>ordering of i and j happens to be. Not good. Maybe looping over all
>posibilities for a symmetric tensor would need to be done.
Yes that is true and alas...T is most of the time symmetric in the example I
gave. Maybe looping could be a good solution
>I'm not sure whether I will have time to implement this, though.
Chris, I even could not say that all these things are extremely important.
I my case most of the time I am interested in computing
products such as T.i.j*D.i.j numerically.
But I would like to be able to make use of symbolic math in order to:
1) to get some simplifications so as to have less terms to compute
2) to expand tensor expressions (combinations of sums and products) in
(as I think is done in some libraries that use expression templates like
in order to reduce the loss of performance of C++ with respect to fortran o
3) to do some analytical differentiation of terms
I think these types of things could make a code more general, powerful and
I hope Ginac could help me on that.
More information about the GiNaC-list