News from the gTybalt corner

[Stefan Weinzierl]

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