search

vermaseren / form

The FORM project for symbolic manipulation of very big expressions
GNU General Public License v3.0
1.14k stars 136 forks source link

Dummy indices in functions? #150

Open tueda opened 7 years ago

tueda commented 7 years ago

This may be out of the scope of the current implementation of dummy indices, but I expect the following program gives only one term after canonicalizing summed indices:

CF f1,f2,vec,g(symmetric);
V p;
I mu1,...,mu9;

L F =
  + f1(vec(p,mu1)*vec(p,mu2)*vec(p,mu3)*vec(p,mu4)*g(mu1,mu2)*g(mu3,mu4)) *
    f2(vec(p,mu5)^2)
  + f1(vec(p,mu1)*vec(p,mu2)*vec(p,mu3)*vec(p,mu4)*g(mu1,mu3)*g(mu2,mu4)) *
    f2(vec(p,mu6)^2)
  + f1(vec(p,mu1)*vec(p,mu2)*vec(p,mu3)*vec(p,mu4)*g(mu1,mu4)*g(mu2,mu3)) *
    f2(vec(p,mu7)^2)
;
sum mu1,...,mu9;
renumber,1;
P +s;
.end

Unfortunately, that is not the case:

FORM 4.1 (Nov 24 2016, v4.1-20131025-270-g6fe5632) 64-bits  Run: Fri Nov 25 13:35:18 2016

   F =
       + f1(vec(p,N1_?)*vec(p,N2_?)*vec(p,N3_?)*vec(p,N4_?)*g(N1_?,N2_?)*g(
      N3_?,N4_?))*f2(vec(p,N5_?)^2)
       + f1(vec(p,N1_?)*vec(p,N2_?)*vec(p,N3_?)*vec(p,N4_?)*g(N1_?,N3_?)*g(
      N2_?,N4_?))*f2(vec(p,N5_?)^2)
       + f1(vec(p,N1_?)*vec(p,N2_?)*vec(p,N3_?)*vec(p,N4_?)*g(N1_?,N4_?)*g(
      N2_?,N3_?))*f2(vec(p,N5_?)^2)
      ;

Note that the indices in f2 are all changed to N5_?. This means FORM manages to sum up the indices in such a way that it doesn't conflict with indices in another function f1, not making f2(vec(p,N1_?)^2). But then FORM doesn't try for interchanges of indices like mu2 <-> mu3.

One can easily check that the three terms in the above program are indeed equivalent by

id f1(x?) = x;
id f2(x?) = 1;  * ignore f2(vec(p,N5_?)^2)
renumber,0;
vermaseren commented 7 years ago

You are hitting here on a (by now) known problem that dummy indices inside functions inside functions do not get handled well. Sometimes there can even be errors. This is why the ‘fast’ handling of color in convdia with the use of diacolor.h does not work well when there are open indices. For the moment I am trying to hack around this, because it has all the looks like this is going to be very complicated to track down and fix. At the moment I have no time for it.

Jos

On 25 nov. 2016, at 13:50, Takahiro Ueda notifications@github.com wrote:

This may be out of the scope of the current implementation of dummy indices, but I expect the following program gives only one term after canonicalizing summed indices:

CF f1,f2,vec,g(symmetric); V p; I mu1,...,mu9;

L F =

  • f1(vec(p,mu1)vec(p,mu2)vec(p,mu3)vec(p,mu4)g(mu1,mu2)g(mu3,mu4)) f2(vec(p,mu5)^2)
  • f1(vec(p,mu1)vec(p,mu2)vec(p,mu3)vec(p,mu4)g(mu1,mu3)g(mu2,mu4)) f2(vec(p,mu6)^2)
  • f1(vec(p,mu1)vec(p,mu2)vec(p,mu3)vec(p,mu4)g(mu1,mu4)g(mu2,mu3)) f2(vec(p,mu7)^2) ; sum mu1,...,mu9; renumber,1; P +s; .end Unfortunately, that is not the case:

FORM 4.1 (Nov 24 2016, v4.1-20131025-270-g6fe5632) 64-bits Run: Fri Nov 25 13:35:18 2016

F =

  • f1(vec(p,N1?)*vec(p,N2?)vec(p,N3_?)vec(p,N4?)*g(N1?,N2?)*g( N3?,N4?))*f2(vec(p,N5?)^2)
  • f1(vec(p,N1?)*vec(p,N2?)vec(p,N3_?)vec(p,N4?)*g(N1?,N3?)*g( N2?,N4?))*f2(vec(p,N5?)^2)
  • f1(vec(p,N1?)*vec(p,N2?)vec(p,N3_?)vec(p,N4?)*g(N1?,N4?)*g( N2?,N3?))*f2(vec(p,N5?)^2) ; Note that the indices in f2 are all changed to N5?. This means FORM manages to sum up the indices in such a way that it doesn't conflict with indices in another function f1, not making f2(vec(p,N1?)^2). But then FORM doesn't try for interchanges of indices like mu2 <-> mu3.

One can easily check that the three terms in the above program are indeed equivalent by

id f1(x?) = x; id f2(x?) = 1; * ignore f2(vec(p,N5_?)^2) renumber,0; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/150, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEmkjIbXFAJWS9UHLhSAwA_5MfpBoks5rBtmygaJpZM4K8aYn.

vermaseren commented 7 years ago

Hi Takahiro,

I am struggling with this one again and what happens is the following: You have a function f with various terms in its argument(s). Now when you have dummy indices in those terms of each term it should know which one is the maximum one, and for the complete term at bottom level it should know the maximum of all of those. There is nothing that keeps track of this. Building it in will not be simple unless we sacrifice a lot of speed by sampling it all the time. Even then, a renumber inside an argument is extremely dangerous if there is more than one function. This will need much thought and I will have to avoid the use of diacolor.h Too bad.

Cheers

Jos

On 25 nov. 2016, at 14:15, Jos Vermaseren t68@nikhef.nl wrote:

You are hitting here on a (by now) known problem that dummy indices inside functions inside functions do not get handled well. Sometimes there can even be errors. This is why the ‘fast’ handling of color in convdia with the use of diacolor.h does not work well when there are open indices. For the moment I am trying to hack around this, because it has all the looks like this is going to be very complicated to track down and fix. At the moment I have no time for it.

Jos

On 25 nov. 2016, at 13:50, Takahiro Ueda <notifications@github.com mailto:notifications@github.com> wrote:

This may be out of the scope of the current implementation of dummy indices, but I expect the following program gives only one term after canonicalizing summed indices:

CF f1,f2,vec,g(symmetric); V p; I mu1,...,mu9;

L F =

  • f1(vec(p,mu1)vec(p,mu2)vec(p,mu3)vec(p,mu4)g(mu1,mu2)g(mu3,mu4)) f2(vec(p,mu5)^2)
  • f1(vec(p,mu1)vec(p,mu2)vec(p,mu3)vec(p,mu4)g(mu1,mu3)g(mu2,mu4)) f2(vec(p,mu6)^2)
  • f1(vec(p,mu1)vec(p,mu2)vec(p,mu3)vec(p,mu4)g(mu1,mu4)g(mu2,mu3)) f2(vec(p,mu7)^2) ; sum mu1,...,mu9; renumber,1; P +s; .end Unfortunately, that is not the case:

FORM 4.1 (Nov 24 2016, v4.1-20131025-270-g6fe5632) 64-bits Run: Fri Nov 25 13:35:18 2016

F =

  • f1(vec(p,N1?)*vec(p,N2?)vec(p,N3_?)vec(p,N4?)*g(N1?,N2?)*g( N3?,N4?))*f2(vec(p,N5?)^2)
  • f1(vec(p,N1?)*vec(p,N2?)vec(p,N3_?)vec(p,N4?)*g(N1?,N3?)*g( N2?,N4?))*f2(vec(p,N5?)^2)
  • f1(vec(p,N1?)*vec(p,N2?)vec(p,N3_?)vec(p,N4?)*g(N1?,N4?)*g( N2?,N3?))*f2(vec(p,N5?)^2) ; Note that the indices in f2 are all changed to N5?. This means FORM manages to sum up the indices in such a way that it doesn't conflict with indices in another function f1, not making f2(vec(p,N1?)^2). But then FORM doesn't try for interchanges of indices like mu2 <-> mu3.

One can easily check that the three terms in the above program are indeed equivalent by

id f1(x?) = x; id f2(x?) = 1; * ignore f2(vec(p,N5_?)^2) renumber,0; — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/150, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEmkjIbXFAJWS9UHLhSAwA_5MfpBoks5rBtmygaJpZM4K8aYn.

tueda commented 7 years ago

I can imagine it would be very tricky. And could be slow. Maybe we can add a kind of dirty flag for each function indicating dummy indices-free to skip the costly check if not needed.

vermaseren commented 7 years ago

Hi Takahiro,

For the moment the best is a warning not to do these things with probably a small example. I am still not sure what would constitute a good solution when more than one function is involved as in f(terms with dummy indices)*f(terms with dummy indices) I tried (I had one one function) to stick in lots of renumber statements, but that did not help. I still had terms in the function argument in which the only dummy index was N2_?. Clearly things do not work right there. I switched down to color.h and am now checking how well things go. Probably means that we may have to rerun everything at the 5-loop level. Or at least check that the color factors do not change.

Cheers

Jos

On 26 nov. 2016, at 19:50, Takahiro Ueda notifications@github.com wrote:

I can imagine it would be very tricky. And could be slow. Maybe we can add a kind of dirty flag for each function indicating dummy indices-free to skip the costly check if not needed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/vermaseren/form/issues/150#issuecomment-263079446, or mute the thread https://github.com/notifications/unsubscribe-auth/AFLxEtT7svPv9DQUn_mAbMLONLxFLjecks5rCH-PgaJpZM4K8aYn.