Hi, Thanks a lot for your suggestions! On Wed, 31 Jul 2002, Chris Dams wrote:
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.
I really don't see any good way out of this, given that any expression may be a highly non-treeish directed acyclic graph in GiNaC. How should such a class largeadd interfere with the normal add class? We do care that it works on platforms with 64 Bit ABI thus ensuring that it still runs fine when you have pervert amounts of RAM, and I repeatedly checked that it scales well there. So, I recommend investing money in memory. I don't want to hold you back if you have any bright idea, but I really don't see many possiblities. A personal piece of Sci-Fi: I don't even believe in hard disks having any future. You probably noticed that IBM backed out of this business a while ago. IMHO, one of the reasons is that they believe in something else, too. They do hold a fair amount of patents on holographic storage (without movable parts) and maybe in five years we'll see hardware where the distinction between RAM and disk is blurred by the presence of huge amounts of fast holographic memory. I would even bet on this. Also, the difference between memory-speed and disk-speed has only been widening during the last three decades.
(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.
Oh, if you want such an expand_option, just go ahead and send us a patch! The change should be fairly trivial, indeed.
(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.
Doesn't this only boil down to shorter notation? I don't see why this would really reduce the amount of indeces? Aren't they just swept under the rug?
(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.
Hmm, maybe... luck -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>