possible improvements

[Richard B. Kreckel]

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 at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>