[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