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

Vladyslav Shtabovenko v.shtabovenko at tum.de
Tue Jan 6 02:04:44 CET 2015


Dear Vladimir,

for the optimization strategy I would have a look at what FORM does.

The algorithm is described here
<http://www.nikhef.nl/~form/maindir/documentation/reference/online/online.html#gammaalgebra>

and the corresponding C code is available on GitHub:

<https://github.com/vermaseren/form/blob/master/sources/opera.c>

Cheers,
Vladyslav



Am 04.01.2015 um 20:36 schrieb Vladimir V. Kisil:
>>>>>> On Sun, 04 Jan 2015 18:53:51 +0100, Vladyslav Shtabovenko <v.shtabovenko at tum.de> said:
>     VSh> 1) By repeatedly applying the anticommutation relations to move
>     VSh> g_mu through all other matrices to g^mu. This is the easiest
>     VSh> but also the slowest way to implement.
> 
>     This is what GiNaC is using, as far as I understand.
> 
>     VSh> (people mostly care only about traces), it might be reasonable
>     VSh> to look at the performance of dirac_trace instead.
> 
>     IMHO, this routine still uses clifford::eval_ncmul(), which I think
>   is the principal bottleneck.
> 
>     VSh> takes around 5 seconds on my machine, a similar code with FORM
>     VSh> requires less than 0.01 seconds. With FeynCalc
> 
>     Probably, GiNaC will never do a particular task as good as
>   a specialised software. GiNaC allows to mix all types of objects in a
>   single expression, so all simplifying algorithms need to be of a very
>   plain generic nature.
> 
>     VSh> So I think that it would be very nice if someone of the GiNaC
>     VSh> developers could have a look at this issue.
> 
>     I am not familiar with Dirac matrices close enough to optimise the
>   performance beyond the simple anticommutation. It will be good if you can
>   come with some optimisation suggestions of clifford::eval_ncmul().
> 
>   Best wishes,
>        Vladimir
> 


More information about the GiNaC-list mailing list