Hello everybody,
I have been thinking about some improvements for GiNaC that I might want
to see implemented and that I might even have a try at myself. No
guarantees that I will do anything, but I just might if I find some time.
Before doing anyting, however, I would like to know what GiNaCs
authors/maintainers think of my "improvements". Which of them would they
include in the library, if they were implemented?
Well, here they are:
(1) Sometimes I find that GiNaC expressions can become so large that I run
out of memory. Having a swapping GiNaC running on a computer is terrible.
Technically speaking it does not crash the computer, however practically
speaking, it is as good as a crash. Typically this happens for expressions
that are large sums of which most terms are multiplications. Wouldn't it
be nice to have a new class "largeadd" that stores its terms in a file
rather then in memory. (If terms are products these would be saved in the
file too, but the factors themselves would probably be kept in memory.)
For the user, the most sensible way of manipulating a largeadd would be to
have a map_function acting on it, performing various tasks at once, so
that the terms in the largeadd do not need to be retrieved and stored too
often.
(2) Introduce a new expand_option that prevents GiNaC from expanding
inside powers with exponents that aren't positive integers. For example, a
user might want to have (a+b)^2*(1+(x+y)^2)^(-1) expanded into
a^2*(1+(x+y)^2)^(-1) + 2*a*b*(1+(x+y)^2)^(-1) + b^2*(1+(x+y)^2)^(-1)
instead of having the denominator expanded too.
(3) Using so-called schoonschip-notation for indexed objects. The
idea is that if an object with one index is contracted with another
object, the base-expresion of the one-index-object is put at the position
where the index occurs that it is contracted with.
Example: A.mu~nu*p~mu --> A(p,~nu)
Note that this would require indexed objects to be able to take non-idx
expressions as arguments. Also one would want to introduce the notion of
an inner product, leading to the automatic simplification rule: p.mu*q~mu
--> inp(p,q). The point is that this often greatly reduces the amount of
indices thereby allowing further simplifications. Also one no longer needs
to call simplify_indexed, which, at times, is a somewhat expensive
function.
(4) Haven't really looked at this terribly carefully yet, but I suppose
the function dirac_trace can be made much more efficient. The idea of
expanding gamma5 into eps(i1,i2,i3,i4)*gamma(i1)*...*gamma(i4) (which
happens inside the function dirac_trace) really looks like a winner for
the award for inefficient algorithms. Also, there could be made a function
that takes the trace of all spin-lines at the same time, using the
Chisholm identity whenever possible. I would guess that this also makes
things much faster.
Greetings,
Chris Dams