Linearization of anti-symmetric function

[Chromomaniac]

I am writing to ask for clarification regarding an issue I've encountered in FORM related to the loss of antisymmetric behavior in a user-defined commuting function.

To illustrate the problem, I have attached test code below. The function in question is essentially a user-defined rank-4 Levi-Civita tensor, which I denote as Levieps(p1, p2, p3, p1 + p2). My goal is to linearize the fourth argument (p1 + p2) using SplitArg, with the expectation that the resulting expression vanishes due to the antisymmetric properties of the Levi-Civita symbol.

To avoid writing specific id statements for each possible argument combination, I attempt to generalize the approach by applying SplitArg and converting to non-commuting functions. However, once the expression is linearized, the antisymmetric nature appears to be lost, and the result does not vanish as expected.

Here is the test code:

#-
off statistics,finalstats,allwarnings;
FunPowers allfunpowers;
Autodeclare vector p;
Autodeclare index mu,nu,alpha,beta,la,si;
CF Levieps(antisymmetric);
F GammaMF;

g TraceExpr = Levieps(p1, p2, p3,p1+p2);
.sort;
Chainout Levieps;
splitarg;
id Levieps(mu?) = GammaMF(mu);
id Levieps(mu?,nu?) = GammaMF(mu) + GammaMF(nu);
id GammaMF(mu?) = Levieps(mu);
Chainin Levieps;
.sort

print+s TraceExpr;
.end

[jodavies]

Here's the information from our emails:

After the ChainIn it seems Levieps is not checked again w.r.t symmetry properties. Dirtying the arguments with, for eg, Argument Levieps; EndArgument; is a workaround.

This can be resolved by adding MarkDirty(term, DIRTYSYMFLAG); to the end of ChainIn in function.c but I am not completely sure yet if this is the best place to modify the code.

[tueda]

Has this ChainIn dirty flag bug been filed as an issue?

[jodavies]

No, but this should go in for 4.3.2 and 5.0.

[jodavies]

The proposed fix doesn't actually work if there is no sort, for eg:

#-
Off stats;

CFunction eps(antisymmetric);
Vector p1,p2,p3;

Local zero = eps(p1,p2,p3,p1+p2);

ChainOut eps;
SplitArg eps;
Repeat Identify eps(p1?,p2?) = eps(p1)+eps(p2);
ChainIn eps;
*.sort

Print;
.end

[jodavies]

OK: you need to do MarkDirty(term, DIRTYSYMFLAG); Normalize(BHEAD term);. @vermaseren : is directly in ChainIn the right place for this code? Generator does not seem to re-do any normalization for these function calls that sit in the Special action fold.

(ChainOut, for eg, calls Normalize directly)

[jodavies]

Also of note is that the manual claims This statement is obsolete. The user should try to use the funpowers option of the on (see [7.107] or the off (see [7.106]) statements. but that option doesn't exist there and I don't see it in the code either.

[tueda]

This is not a generally applicable method, but it may be useful in diagrammatic calculations (like p4 := [p1+p2] is a momentum generated by a diagram generator):

Auto V p;
V [p1+p2];
CT eps(antisymmetric);
L F = eps(p1, p2, p3, [p1+p2]);
id [p1+p2] = p1 + p2;
P;
.end

which gives

   F = 0;

This works because eps(p1, p2, p3, [p1+p2]) represents eps(mu1, mu2, mu3, mu4)*p1(mu1)*p2(mu2)*p3(mu3)*[p1+p2](mu4).

[jodavies]

Fixed in #658 . Still there is the manual-related issue.

Correction: this was actually fixed in #657 .