From Chris.Dams at mi.infn.it Tue Jan 3 13:00:06 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Tue, 03 Jan 2006 13:00:06 +0100 Subject: [GiNaC-devel] Improvements for algebraic substitutions. Message-ID: <1136289606.8057.6.camel@pcnason2.mi.infn.it> Happy new year! I found out that if we do (notation simplified to be more readable but less compilable): (a^n*b^m*b^p).subs($0^$1*$0^$2==$0^($1+$2),subs_options::algebraic) nothing happens because a^n already matches a factor in the pattern and in that case no other matches are attempted. I fixed this. Also, I allowed algebraic substitution to match multiple times on different factors with the same pattern. E.g. the above .subs() can be used to simplify a^n*a^m*b^p*b^q -> a^(n+m)*b^(p+q) These changes are in CVS. Bye, Chris From Chris.Dams at mi.infn.it Wed Jan 4 16:33:57 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 04 Jan 2006 16:33:57 +0100 Subject: [GiNaC-devel] Bug in clifford::subs(). Message-ID: <1136388837.3799.3.camel@pcnason2.mi.infn.it> Dear all, I found out that if there is nothing to substitute for clifford::subs it does not return an expression that is trivially equal (in the sense of are_ex_trivially_equal) to the original one. Besides that there were a lot of overloaded clifford::subs methods of which the purpose is unclear to me. I removed these spurious methods and fixed the bug. The patch is in CVS. Best wishes, Chris From Chris.Dams at mi.infn.it Wed Jan 4 18:49:23 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 04 Jan 2006 18:49:23 +0100 Subject: [GiNaC-devel] Another bug in clifford.cpp Message-ID: <1136396963.4133.6.camel@pcnason2.mi.infn.it> Dear all, I found out that canonicalizing clifford objects was not functioning properly. This was because a dirac_slash was automatically getting zero as its metric. When canonicalizing clifford objects the anti-commutator of two objects that were ordered in the wrong way is necesary. However, if the metric is automatically set to zero, this anti-commutator is zero too. I fixed this in CVS. I do have two questions about the implementation (1) Why are the indices in dirac_gamma (and with my patch in dirac_slash) static? Does the dimension of them not matter? It now seems that the dimension as used in the metric is always equal to the dimension of the very first dirac_gamma/dirac_slash that is constructed. (2) Why does the metric have indices? In view of the implementation of get_metric the primary purpose of these indices seems to be to be replaced by other indices. If that is the case why are they present in the first place? Best, Chris From kisilv at maths.leeds.ac.uk Wed Jan 4 20:20:33 2006 From: kisilv at maths.leeds.ac.uk (Vladimir Kisil) Date: Wed, 04 Jan 2006 19:20:33 +0000 Subject: [GiNaC-devel] Another bug in clifford.cpp In-Reply-To: Your message of "Wed, 04 Jan 2006 18:49:23 +0100." <1136396963.4133.6.camel@pcnason2.mi.infn.it> Message-ID: I cannot say anything about dirac_slash, thus here are some comments on the second topic: >>>>> "CD" == Chris Dams writes: CD> (2) Why does the metric have indices? It will be nice to combine two things: (a) to standardise storage of metric to an object of certain type; (b) to have a freedom to define metric from many different objects like matrices or tensors. Thus indexed object is chosen as a standard storage for a metric with its first component to hold actual metric (e.g. matrix or tensor). Indices are indeed somehow superficial but having some default values for them seems to be useful for example in same_metric(). Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv at maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ From Chris.Dams at mi.infn.it Thu Jan 5 12:20:24 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Thu, 5 Jan 2006 12:20:24 +0100 (CET) Subject: [GiNaC-devel] Another bug in clifford.cpp In-Reply-To: Message-ID: Dear Vladimir, On Wed, 4 Jan 2006, Vladimir Kisil wrote: > Thus indexed object is chosen as a standard storage for a metric with > its first component to hold actual metric (e.g. matrix or > tensor). Indices are indeed somehow superficial but having some > default values for them seems to be useful for example in > same_metric(). However, also in same_metric, get_metric is called and that replaces the indices. So maybe there is an example in which the indices serve a purpose but it does not seem to be in the same_metric function. The alternative that would seem to be more logic is to store the thing that should take the indices. For instance a matrix or a minkmetric. In that case get_metric would not have to substitute indices but could merely return indexed(metric, i, j). Is the purpose of having the metric inside an indexed object to also store the symmetry of the metric? Best wishes, Chris From kisilv at maths.leeds.ac.uk Thu Jan 5 12:50:45 2006 From: kisilv at maths.leeds.ac.uk (Vladimir Kisil) Date: Thu, 05 Jan 2006 11:50:45 +0000 Subject: [GiNaC-devel] Another bug in clifford.cpp In-Reply-To: Your message of "Thu, 05 Jan 2006 12:20:24 +0100." Message-ID: >>>>> "CD" == Chris Dams writes: CD> However, also in same_metric, get_metric is called and that CD> replaces the indices. Currently same_metric replaces the indices with indices from the metric of another clifford object (assuming that they are present). CD> indexed(metric, i, j). Is the purpose of having the metric CD> inside an indexed object to also store the symmetry of the CD> metric? Yes, this is another important reason which I forgot to mention. Besides that the presence of indeces keep record on the dimensionality of the Clifford algebra. Otherwise it need to be stored separately if the metric is given for example by minkmetric. Overall keeping metric as indexed object can provide some important info on generic Clifford algebra which otherwise would be lost. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv at maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/ From Chris.Dams at mi.infn.it Tue Jan 10 15:21:28 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Tue, 10 Jan 2006 15:21:28 +0100 Subject: [GiNaC-devel] Index dimensions. Message-ID: <1136902888.26882.3.camel@pcnason2.mi.infn.it> Dear all, I have modified the function minimal_dim in idx.cpp so that non-numerical dimensions do not have to be symbols. For instance minimal_dim(4,4-2*delta) will return 4. Generally a numeric dimension will always be considered smaller than a non-numeric dimension. This makes sense in the context of dimensional regularization. Best wishes, Chris From kreckel at ginac.de Tue Jan 10 22:01:25 2006 From: kreckel at ginac.de (Richard B. Kreckel) Date: Tue, 10 Jan 2006 22:01:25 +0100 Subject: [GiNaC-devel] Index dimensions. In-Reply-To: <1136902888.26882.3.camel@pcnason2.mi.infn.it> References: <1136902888.26882.3.camel@pcnason2.mi.infn.it> Message-ID: <43C420A5.7010607@ginac.de> Chris Dams wrote: >Generally a numeric dimension >will always be considered smaller than a non-numeric dimension. This >makes sense in the context of dimensional regularization. > > Does it? Why? curious -richy. -- Richard B. Kreckel From Chris.Dams at mi.infn.it Wed Jan 11 10:00:22 2006 From: Chris.Dams at mi.infn.it (Chris Dams) Date: Wed, 11 Jan 2006 10:00:22 +0100 Subject: [GiNaC-devel] Index dimensions. In-Reply-To: <43C420A5.7010607@ginac.de> References: <1136902888.26882.3.camel@pcnason2.mi.infn.it> <43C420A5.7010607@ginac.de> Message-ID: <1136970022.6409.4.camel@pcnason2.mi.infn.it> Dear Richy, On Tue, 2006-01-10 at 22:01 +0100, Richard B. Kreckel wrote: > >Generally a numeric dimension > >will always be considered smaller than a non-numeric dimension. This > >makes sense in the context of dimensional regularization. > > Does it? Why? Because when defining integration in an arbitrary number of dimensions, as it is done in the book "Renormalization" by Collins, vectors are considered to have an infinite number of components as in p(p_1, p_2, ...). Therefore projection on, say, 4 components reduces the number of them. Best, Chris