[GiNaC-devel] A patch for add::coeff() and new clifford_max_label()

Jens Vollinga vollinga at thep.physik.uni-mainz.de
Wed Apr 20 19:23:15 CEST 2005


Hi Kisil,

On Wed, Apr 20, 2005 at 11:07:29AM +0100, Vladimir Kisil wrote:
>   raises an exception in the second output statement. I think everyone
>   would like it can produce something like "(ONE+gamma~mu)*gamma~nu"
>   instead. And first output should remain "(2+a)*gamma~nu" and not
>   became "(2*ONE+a*ONE)*gamma~nu" on the other hand.

thanks for your patch. It seems to work fine. Nevertheless, I am a bit
reluctant to put it into CVS, because there seems to be a bigger issue
behind the problem:
'collect' basically uses 'coeff' to do its job. But 'coeff' doesn't care
about non-commuting objects. This leads to behavior like the following:

    ...
    ex e = dirac_gamma(nu) * dirac_gamma(mu) + dirac_gamma(sigma) * dirac_gamma(mu);
    cout << e.collect(dirac_gamma(mu)) << endl;

gives

    (gamma~sigma+gamma~nu)*gamma~mu

which is fine, but

    ...
    ex e = dirac_gamma(mu) * dirac_gamma(nu) + dirac_gamma(mu) * dirac_gamma(sigma);
    cout << e.collect(dirac_gamma(mu)) << endl;

gives

    (gamma~sigma+gamma~nu)*gamma~mu-gamma~nu*gamma~mu-gamma~sigma*gamma~mu+gamma~mu*gamma~sigma+gamma~mu*gamma~nu

which is not wrong but strange.

With non-commuting objects one probably needs to distinguish between a
left coefficient and a right coefficient. Fixing this problem likely
changes the way the ONE-Problem can be addressed. So, at the moment I am
not sure what to do.

Regards,
Jens





More information about the GiNaC-devel mailing list