Improved dummy index renaming -> clifford exam fails
Dear all, I have improved the dummy index renaming. Now dummy indices are (if necessary) also renamed after mul::map is called. I made the code a bit nicer. All of the renaming is now done in either expairseq::make_flat(const exvector &v) or in expairseq::make_flat(const epvector &v). So, there is no renaming code anymore in subschildren because the renaming is taken care of by expairseq::make_flat. I did introduce a boolean parameter to some methods that says whether or not to do dummy index renaming. I also commented out some of the tests in exam_clifford.cpp. They started failing but I really don't consider this my fault. Anyone who writes code like indexed(squared_metric, alpha, alpha) where alpha is a varidx should realize that he is in a state of sin and really doing something that might break anytime. In clifford.cpp there is a lot of such code. Of course, I tried to fix it but then other things started breaking. My conclusion is that I'm going to wish "happy debugging" to Vladimir. In particular I don't really understand what the code in the .is_anticommuting() branches in cliffordunit::contract_with are supposed to be useful for. By the way. Wouldn't it be a good idea to remove the restriction that indices of clifford objects should be varidxes? When allowing a matrix as metric I do not really see the use of the varidxes. Doesn't an up-index mean exactly the same as a down one in that case? What I also would like to know, is what on earth it means that "generators satisfying the identities e~i e~j + e~j e~i = M(i, j) for some matrix (metric) M(i, j), which may be non-symmetric". From the e~i e~j + e~j e~i = M(i, j) it follows immediately that M(i,j) = M(j,i), doesn't it? Other changes: (1) moved the inline unsigned rotate_left(unsigned n) function from utils.h to ex.h because it can be quite useful for people writing their own classes and needing a hash function. (2) Changed the code for algebraic substitutions. This was necessary to keep it possible to use a pattern like U.$0.$1*Uinv.$1.$2 -> delta.$0.$2 for algebraic substitutions. (3) Added a few GiNaC::-prefixes in registrar.h to make it possible to declare algebraic classes outside the GiNaC namespace. Best wishes, Chris
Quoting Chris Dams <Chris.Dams@mi.infn.it>:
started breaking. My conclusion is that I'm going to wish "happy debugging" to Vladimir.
I am out today for a couple of weeks and will look on this after come back. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk
Dear All, I am going to fix problems pointed out by Chris in clifford.cpp. However I looking for developer's advises before that.
"CD" == Chris Dams <Chris.Dams@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. CD> By the way. Wouldn't it be a good idea to remove the restriction CD> that indices of clifford objects should be varidxes? I am going to remove this if nobody objects. CD> varidxes. Doesn't an up-index mean exactly the same as a down CD> one in that case? 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 however e.i e~j + e~j e.i = delta.i~j Does any one object to implementation of the last identity in GiNaC? Or e.i e~j + e~j e.i = g.i~j should be used instead? 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 e~i e~j + e~j e~i = M(i, j) + M(j, i) which is meaningful for non-symmetric M. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/
Dear Vladimir, On Fri, 11 Aug 2006, Vladimir Kisil wrote:
"CD" == Chris Dams <Chris.Dams@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
"CD" == Chris Dams <Chris.Dams@mi.infn.it> writes: CD> Here one CD> clearly sees that neither contractiong g~mu~mu nor g.mu.mu makes CD> any sense.
The mentioned expression indexed(squared_metric, alpha, alpha) did not stand for a contractions, it was simply an abbreviation for pow(e.alpha,4)=pow(g.alpha.alpha,2). However I will rewrite clifford.cpp without this sort of "optimisation". CD> This is why I was wondering in an CD> earlier email whether we should even allow matrices to carry CD> indices with a variance. If g is the metric tensor g with up CD> indices should be the inverse of g with down indices. Why not use the agreement from the second sentence to make sense for the first one? CD> If g is the metric tensor, it automatically obeys g.i~j = CD> delta.i~j. Actually, this simplification is done automatically CD> in GiNaC. It is in the function ex CD> tensmetric::eval_indexed(const basic & i) const. So I only need take care on it if metric is given by a matrix? Best, Vladimir -- Vladimir V. Kisil email: kisilv@maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/
participants (3)
-
Chris Dams
-
Vladimir Kisil
-
Vladimir V Kisil