News from the gTybalt corner
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
Hi, On Thu, 10 Jan 2002, Stefan Weinzierl wrote: [...] Glad it turned out helpful! [...]
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 ?
Sounds ugly, doen't it? Adding an SU(2) object to an SU(3) object does not make sense mathematically. As you are saying yourself, you are adding "apples" to "potatoes"... Let's think: back to the example about SU(2) and SU(3), one should not add \sigma_1 to \lambda_3. This is reflected in add::return_type() and add::return_type_tinfo() which don't even bother traversing the sum! The invariance that the sum makes sense is not even checked. (Thinking about it, it probably should be checked #if defined(DO_GINAC_ASSERT).) However, you can well add \sigma_1 to \lambda_3 when you first multiply \sigma_1 with the one in SU(3) and the \lambda_3 with the one in SU(2). A mul object is basically a tensorial product, here. When you do all this rigorously, you could even sort out the elements properly. It would be some combination of calls to collect() and coeff(). Is it that, what you want? Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
On Fri, 11 Jan 2002, Richard B. Kreckel wrote:
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.
Sounds ugly, doen't it? Adding an SU(2) object to an SU(3) object does not make sense mathematically. As you are saying yourself, you are adding "apples" to "potatoes"...
Let's think: back to the example about SU(2) and SU(3), one should not add \sigma_1 to \lambda_3. This is reflected in add::return_type() and add::return_type_tinfo() which don't even bother traversing the sum! The invariance that the sum makes sense is not even checked. (Thinking about it, it probably should be checked #if defined(DO_GINAC_ASSERT).)
However, you can well add \sigma_1 to \lambda_3 when you first multiply \sigma_1 with the one in SU(3) and the \lambda_3 with the one in SU(2). A mul object is basically a tensorial product, here.
When you do all this rigorously, you could even sort out the elements properly. It would be some combination of calls to collect() and coeff(). Is it that, what you want?
Hi Richy, what I would like to do is to write \sigma_1 + \lambda_3 when I mean \sigma_1 * ONE_su3 + ONE_su2 * \lambda_3 to avoid a proliferation of unit elements of various algebras. This would give a better readability of results and would be more efficient. Calls to coeff() and collect() have to transverse the whole expression tree, and in routines which have to be efficient I would like to avoid such "global" operations as much as possible. A container for the addition of mixed type elements would just be the missing piece in GiNaC. Of course, one can have a philosophical discussion, if it would make sense to write \sigma_1+\lambda_3 down in the first place, but I'm using the non-commutative feature in a slightly different context. It is more about expressions of the form 1 + x + pow(x,2) + LOG(x) where LOG(x) is an instance of a class with special simplification rules: LOG(x)*LOG(y) = Li2(x*y) + other terms This multiplication rule can be implemented very elegantly in GiNaC if I declare the "LOG"-class non-commutative and put the multiplication in simplify_ncmul. But a lot of this elegance and efficiency is lost, if I'm forced to write 1*ONE + x*ONE + pow(x,2)*ONE + LOG(x) where ONE is the unit in the algebra of the "LOG"'s. Best wishes, Stefan
participants (2)
-
Richard B. Kreckel
-
Stefan Weinzierl