[GiNaC-list] Performance of simplify_indexed on long chains of Dirac matrices

Vladyslav Shtabovenko v.shtabovenko at tum.de
Mon Jan 26 00:51:03 CET 2015

Dear Vladimir,

thanks for your efforts and the clarification.

Personally, I'm using GiNaC mostly for
cross-checking results obtained with other tools, so that the
performance is not the main issue for me. However, it was
interesting to learn the background of the slowness on large traces.


Am 24.01.2015 um 00:46 schrieb Vladimir V. Kisil:
> 	Dear Vladyslav,
> 	I made some attempts but failed to optimise the GiNaC
>   performance in contracting Dirac gammas. In my opinion the reason is,
>   that the competitors are tailored for this particular problem and
>   the ideology of GiNaC does not allow it to be as effective.
>   GiNaC is highly extendable from its design. A user may define a new
>   object which will be able to contract with the pre-defined Dirac
>   gammas in any manner, which the user will define in his code. So, the
>   core GiNaC does not have a choice but proceed in very general (an
>   inefficient!) manner: contract or permute one Dirac gamma with
>   something else, then make an expansion of the new expression and then
>   recursively apply all the previous steps to every new
>   sub-expression. So, the number of sub-expression and recursive calls
>   (exponentially?) grows with the increment of number of Dirac gammas in
>   the initial product.
>   If you do need a fast computations with Dirac gammas in GiNaC, then
>   you have to derive a new class for them straight from GiNaC::basic and
>   implement those algorithms, which other software use. Present gammas
>   are derived from GiNaC::indexed and have to obey all generic rules
>   implemented in simplify_indexed() method, which are very costly.
>   Best wishes,
>   Vladimir

More information about the GiNaC-list mailing list