[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