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