News from the gTybalt corner

[Richard B. Kreckel]

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 at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>