DoPolarizationSums returns a 3x value

[tueda]

Hi. I know the FeynCalc documentation (on the master branch) says, for DoPolarizationSums[exp, k, ...], exp must contain a valid pair of the polarisation vectors, so the user is responsible for passing a proper expression (that's why I don't post this as a bug report). But I think it would be safer and user-friendly if the following cases could be handled:

1. DoPolarizationSums[exp, p] shouldn't change exp when p is not in expr, and should return just expr.

   Current behaviour (v9.3.1):

   DoPolarizationSums[x, p]

   gives

   

2. Forbid applying DoPolarizationSums to an invalid expression, e.g., abort with showing DoPolarizationSums::failmsg, cf. Forbid DoPolarizationSums with negative momenta #137.

   Current behaviour (v9.3.1):

   exp = Conjugate[PolarizationVector[p, mu]] PolarizationVector[p, nu] PolarizationVector[p, rho]
   DoPolarizationSums[exp, p]

   gives

   

[vsht]

I've been thinking about your suggestions, but currently I don't see an obvious way to implement them:

1. In principle one could also assign explicit values to products of two polarization vectors, say ep(p).ep*(p) = -1 in 4D. In this
   case one must multiply by the number of polarizations for consistency reasons. This applies both to expressions containing
   no polarization vectors at all or those that contain terms with and without polarization vectors.

One could add an info message when terms lacking polarization vectors are encountered, though.

On the other hand, it is also not entirely clear to me where such issues may occur. Why would someone want to apply
DoPolarizationSums to an expression lacking polarization vectors?

2. This is not really practical for performance reasons. In the current form, the function just needs to replace Polarization with
   LorentzIndex and multiply the overall expression by the correct polarization sum. If you set the Contract option to False,
   you can see the resulting expression. Notice that here it doesn't really matter whether the input expression is somehow factorized or not.

To be able to catch cases that you mention one would have to multiply everything out and count the number of polarization vectors
in each term. Which can be very expensive performance-wise.

[vsht]

I did some refactoring of the function in the dev version and as a side effect your example would
now actually generate an error, since the correct number of polarization cannot be determined
from looking at the input expression alone (it could be 3 or D-1).

Cf. also the updated documentation page

https://feyncalc.github.io/FeynCalcBookDev/DoPolarizationSums.html

The user would need to enter something like

PolarizationVector[p1, mu] Conjugate[PolarizationVector[p1, nu]]
DoPolarizationSums[%, p2, NumberOfPolarizations -> 3]

and even then there will be a "warning" like

DoPolarizationSums: The input expression contains terms free of polarization vectors. Those will be multiplied with the number of polarizations given by 3.

[tueda]

Thank you! That would be enough, for now, I think.

[tueda]

(By the way, I thought this discussion can be closed because this is now resolved with showing the "warning", but it seems that GitHub has not implemented closing "general discussion"...)

[vsht]

Yes, the discussions feature still seems to be not entirely mature, but it's still better than maintaining a proper externally hosted forum.

BTW, are there any plans for activating discussions in the FORM main repo?

[tueda]

For now, we are not planning it, but I think indeed using GitHub discussions is a good idea.

At least, it can separate simple questions from the Issues, which seems more effective to make a knowledge database.

Another place for questions could be Stack Overflow, but currently I have no privilege to create a tag like form_cas and I'm not sure such a tag for FORM would become popular enough not to be culled.