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

Chris Dams Chris.Dams at mi.infn.it
Mon Jul 24 14:50:33 CEST 2006


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




More information about the GiNaC-devel mailing list