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