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