- GiNaC-devel - ginac.de

Speeding up simplify_indexed(): 2nd try
by Chris Dams 03 Oct '05

03 Oct '05

Dear all, Here is a new attempt at the patch. The problem with the previous one was that if one symmetrizes only amongst indices of precisely the same type, also renaming of indices should be done taking these types into account. Another advantage of this is that if a user uses for instance mu and nu for indices with a variance, these will no longer end up being used as indices without variance. I think this makes output more readable. Best, Chris

1 0

patch for simplify_indexed.
by Chris Dams 01 Oct '05

01 Oct '05

Dear developers, When simplify_indexed() is called two symmetrizations w.r.t dummy indices are performed. In these two cases symmetrization w.r.t. all dummy indices is done. However, it is also possible to do symmetrization with respect to ordinary idx-es, varidx-es and spinidx-es seperately. The latter is potentially much faster. E.g. Today I had an example where some terms contained 5 ordinary dummy indices and 2 dummy indices with variance. In this case a factor of 21 fewer terms are generated by the latter option. (I.e. 7!/5!/2!=21). Therefore symmetrizing seperately can be much faster. A patch is attached. Best wishes, Chris

2 1

Function & Power patch
by Vladimir Kisil 26 Sep '05

26 Sep '05

Dear All, There are many functions (abs, Heaviside, exp) which possess some power-simplification rules. I propose a patch to power.cpp and function.pl which allows to defines such rules in a way similar to derivative rules of functions. With the help of this I slightly improve the definition of abs() and it work now in this way: #include <ginac/ginac.h> using namespace GiNaC; int main(){ realsymbol a("a"); cout << pow(abs(a), 2) << endl; // -> a^2 cout << pow(abs(a), 3) << endl; // -> abs(a)^3 symbol r("r"); cout << pow(abs(r), 2) << endl; // -> abs(r)^2 cout << pow(abs(r), 3) << endl; // -> abs(r)^3 } i.e. pow(abs(a), 2*n) is simplified to pow(a, 2*n) for real a. I also delete a duplicated line from ginac.texi. If it will be useful to add a definition of Heaviside function to the GiNaC core, I can send a patch as well. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

1 0

Patch for adaptivesimpson.
by Chris Dams 15 Sep '05

15 Sep '05

Dear developers, Could you apply the attached patch to integral.cpp? It adds some checks to adaptivesimpson to see whether the boundaries of integration and the integration error really are numbers and, as discussed with Richy, it makes the lookup table take into account that adaptivesimpson may be called with the same integral but different precision. Best wishes, Chris

1 0

Numerical integration in GiNaC
by Richard B. Kreckel 13 Sep '05

13 Sep '05

Hi Chris! I was playing with the adaptive Simpson function and found some problems evaluating numerically a (well-behaved) integral. I've a couple of questions: 1) Why the decision to *not* couple the precision to the value of Digits? Coupling it to Digits would make it available in Ginsh. Wouldn't it do the right thing in almost all cases? 2) Are variations of Simpson's rule really attractive for numerical evaluation? Have you considered/tried something funkier (maybe Romberg's method) or is that a particularly smart implementation? 3) Probably an oversight: the last argument to the adaptivesimpson function is unused. Instead, the code always uses the default. Best wishes -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>

2 3

patch for power::expand_mul
by Chris Dams 09 Sep '05

09 Sep '05

Dear developers, Could you change the line if (get_all_dummy_indices(m).size() > 0) { that occurs in the function power::expand_mul in power.cpp into if (get_all_dummy_indices(m).size() > 0 && n.is_positive()) { Reason: I sometimes use algebraic substitution for expressions involving indices. For instance using the pattern indexed(UL1inv,wildgen,wildgen2)*indexed(UL1,wildgen2,wildgen3) ==delta_tensor(wildgen,wildgen3) to cancel a matrix multiplied with its inverse. Internally, algebraic subsitution divides by the factors it wants to get rid of but since Vladimir Kisils patch this goes wrong if these factors contain a contraction. Best wishes, Chris

1 0

TINFO policy (WAS: [GiNaC-devel] Another clifford patch)
by Vladimir V. Kisil 27 Jul '05

27 Jul '05

>>>>> "RK" == Richard B Kreckel <kreckel(a)ginac.de> writes: RK> This sounds like a helluvagood idea. The only thing I'm worried RK> about is I am also thinking about some kind of policy to choose a right TINFO for new homemade GiNaC classes. It will be good to avoid possible clashes in the case of all such examples collected in one place. Best, -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

1 0

Another clifford patch
by Vladimir Kisil 23 Jul '05

23 Jul '05

Dear All, Here is another patch for Clifford part of GiNaC which contains mainly four components: 1. Some housekeeping alteration of code. 2. Previously GiNaC method is_equal() did not take in account representation labels, i.e. a call dirac_gamma(mu).is_equal(dirac_gamma(mu, 1)) returned true. This leads to miscalculations since for example (dirac_gamma(mu) *(dirac_gamma(mu, 1)).to_rational(L) returned something like pow(symbol7, 2) instead of symbol7*symbol8. I fixed it through an "inclusion" of representation_label as op(2) for dirac_gammas. A fake alteration of let_op(2) is also made. This may not look somewhat trick but I cannot find a better solutions. By the way, does the same problem affects color.cpp? 3. Since metric member variable of the clifford class can contains symbolic entries I add susb() methods which can access metric as well. 4. I add a new member variable commutator sign to clifford class. It is used in the transformations for two clifford instances X and Y as follows: X*Y = commutator_sign*Y*X + 2*metric(X, Y) commutator_sign is an int type and for Clifford algebras is equal to -1. Such an addition with only two lines altered in canonicalize_clifford() allows to derive from clifford class subclasses for Lie algebras (commutator_sign = 1, an demo example is attached) and general algebras defined through commutation identities (e.g. q-deformed algebras can be defined for commutator_sign =0 and a proper construction of the metric). The bubble-sorting realisation of canonicalize_clifford() was initially good for simply anticommuting Dirac gammas. However since the clifford class was very generalised it becomes rather inefficient for high powers of elements and a proper modification is in the "to-do" list. Will it be worth to develop the included Lie algebra subclass into the proper part of GiNaC? Such an addition do break a binary compatibility however this only happens for low level constructors which was recommended to avoid in the user programs. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

3 3

GiNaC 1.3.2 release
by Jens Vollinga 11 Jul '05

11 Jul '05

Hi, GiNaC 1.3.2 is out and available. The changes are: - GCD avoids to produce expanded expressions. - Fixed bug in expanding expressions containing dummy indices. - Fixed static initialization order bug. - collect_common_factors now works with powers. - Modernized configuration scripts. Thanks to all the contributers, especially C.Dams, V.Kisil and A.Sheplyakov. As always, this release can be downloaded from ftp://ftpthep.physik.uni-mainz.de/pub/GiNaC/ Enjoy, Jens Vollinga

1 0

CMCL,a new CAS based on GiNaC
by Qin An 27 Jun '05

27 Jun '05

Dear Christian and Richard, Based on the GiNaC, we have implemented the multivaritate factorization, and embeded in our CAS, CMCL. The CAS/CMCL we built is also on the basis of your open-source symbolic package, GiNaC. And it is compatible with the CAS/Maple's program language. If you and other developers are interested in our CAS/CMCL, please visite the site: http://www.acailab.com/cmcl/cmcl-index.htm Also, as an open project, it is very thankful for you and all the other developers to take part in it. What is more, we need your help , because some problems are not been solved until now, which have been enumerated in the To-Do list. Thanks, Qin An

1 0