News from the gTybalt corner

[Stefan Weinzierl]

Dear all,

I wrote a library based on GiNaC which can handle the expansion
of transcendental functions in a small parameter, like for 
example

 3F2(-2eps,-2eps;1-eps,1-2eps,1-2eps;x) = 1 + 4 Li2(x) eps^2 
                                            + O(eps3)

This is a domain where commercial CAS usually have no clue at
all.
The library is available under GPL from
 http://www.fis.unipr.it/~stefanw/nestedsums

I should also say that at the moment you need GiNaC version 0.8.3,
a migration to the actual GiNaC version is planned for the future.


The rest of the mail is more for the developpers of GiNaC:

First of all my thanks to the developpers of GiNaC, GiNaC
proved to be quite a solid piece of software.
For a part of my program I could do a benchmark test with a
corresponding program written in FORM, and it turned out
that the GiNaC/C++ code was roughly a factor two faster
(as long as all expressions fitted into the available RAM).
Since FORM is mainly known for its speed, this is quite an
achievement.

To the more technical points: 
The algorithms for the expansion of transcendental functions
relies heavily on various algebras, e.g. you have two
elements a1 and a2 in an algebra A and you can multiply them
to get a third element:

   a1 * a2 = a3

Although the algebras are all commutative, I implemented them
as non-commutative objects, then GiNaC automatically groups
elements of the same algebra together and I only have to supply
the actual multiplication routine in the method
 simplify_ncmul
I think, this is handled elegantly and effciently in GiNaC.

However, the expand function does not handle cases if not all
types are the same.
I can even blame myself for making the suggestion that the class
add should throw an exception if it encounters an expression like
 1 + A,
where A is non-commutative.
Right now one is supposed to write
 ONE_in_A + A,
where ONE_in_A is the unit in the algebra of A.
With more than one algebra this becomes rather ugly and inefficient.

My suggestion would be therefore to think about a class
 mixed_type_add in GiNaC, which should have a similar relation
with class add as class ncmul has with class mul:
If all terms in a sum are of the same type, they will end up in class 
add, otherwise in this new class.

I think, that can be implemented efficiently, such that users who do not
care about non-commutative objects will not suffer any severe penalty.
In addition pedantics can check at run-time their expressions and
start a panic attack, if they encounter a class mixed_type_add.

In short, one would have a container, where you can put an "apple" and
a "potato" in.

I had a look at the GiNaC source code, how one would do it, but since
it involves quite a bit of cross links, I would not directly volunteer 
for it.
What do you think ?

 Best wishes,

    Stefan