[GiNaC-devel] Improved dummy index renaming -> clifford exam fails

Chris Dams Chris.Dams at mi.infn.it
Sat Aug 12 16:59:18 CEST 2006


Dear Vladimir,

On Fri, 11 Aug 2006, Vladimir Kisil wrote:

> >>>>> "CD" == Chris Dams <Chris.Dams at mi.infn.it> writes:
>     CD>  Anyone who writes code like
> 
>     CD> 	indexed(squared_metric, alpha, alpha)
> 
>     CD> where alpha is a varidx should realize that he is in a state of
>     CD> sin and really doing something that might break anytime.
> 
> 	Please give me a hint why this is wrong.

The point of objects carrying indices is that it should be clear from the 
indices how this object transforms under transformations of basis. The 
object indexed(squared_metric, alpha, alpha) has no free indices so it 
should be a scalar (i.e., invariant under basis transformations). However, 
it is not. The invariant object would be indexed(squared_metric, alpha, 
alpha.toggle_variance()). Actually, the non-invariance of 
indexed(squared_metric, alpha, alpha) can be so bad that even 
dimensionally it may make no sense. Immagine that we are doing polar 
co-ordinates. The co-ordinates are (r, phi). In physics r may be measured 
in meters and phi is a number. The metric tensor with down-indices is 
given by [ [ 1 [1], 0 [m] ] [ 0 [m], r^2 [m^2] ] ] where I have given the 
units of the various quantities in square brackets. One sees that 
different tensor indices can have different units. The metric tensor with 
up-indices is given by [ [ 1 [1], 0 [1/m] ] [ 0 [1/m], 1/r^2 [1/m^2] ] ].
Here one clearly sees that neither contractiong g~mu~mu nor g.mu.mu makes 
any sense. One is adding up quantities of different dimension. Contracting 
up-indices with down-indices is fine, though.
g~mu~nu * g.mu.nu = g~1~1 [1] * g.1.1 [1] + g~1~2 [1/m] * g.1.2 [m]
	+ g~2~1 [1/m] * g.2.1 [m] + g~2~2 [1/m^2] * g.2.2 [m^2]
Every term is dimensionless.

> 	In the recent paper (p. 4)
>   http://euklid.bauing.uni-weimar.de/templates/papers/f34.pdf the
>   following defining identities of a Clifford algebra in a space with
>   a metric g.i.j are used:
> 
>   e.i e.j + e.j e.i = g.i.j 
>   e~i e~j + e~j e~i = g~i~j 

Yes, that looks like a definition that makes a lot of sense... However,
here g cannot really be seen as a matrix. Because if it is a matrix g.1.1
would be the same as g~1~1 and they need not be. This is why I was
wondering in an earlier email whether we should even allow matrices to
carry indices with a variance. If g is the metric tensor g with up indices
should be the inverse of g with down indices.
 
>   however 
> 
>   e.i e~j + e~j e.i = delta.i~j 

If g is the metric tensor, it automatically obeys g.i~j = delta.i~j.  
Actually, this simplification is done automatically in GiNaC. It is in the
function ex tensmetric::eval_indexed(const basic & i) const.

>     CD> What I also would like to know, is what on earth it means that
>     CD> "generators satisfying the identities e~i e~j + e~j e~i = M(i,
>     CD> j) for some matrix (metric) M(i, j), which may be
>     CD> non-symmetric".
> 
> 	Where did you see this? My ginac.info tells that

Yes, my ginac.info tells the same. I had simply clicked on "tutorial" on 
the GiNaC homepage. The problem is hence that the 1.3 branch has this 
confusing piece of information.
 
Best wishes,
Chris



More information about the GiNaC-devel mailing list