Wrong circular pattern match

[gituliar]

Below is a FORM file with a bug description.

CF PG,PQx, VQQG;
*
*   PG is a gluon propagator
*   PQx is a cut quark propagator
*   VQQG is a quark-quark-gluon veretex
*
T  S(symmetric);

I  s0,...,s99;
I  v1,...,v99;
V  k0,...,k99;
V  p0,...,p9999;

CF Sigma;

*
*  Expression for the gluon self-energy (with one quark loop)
*
L RESULT = PG(S(v17,v18),k3 + k4) * PG(S(v37,v38),k3 + k4) * VQQG(s2,k4,s4,k3,v17, - k3 - k4) * VQQG(s24,k3,s22,k4,v37, - k3 - k4) * PQx(s2,s22,k4) *PQx(s4,s24,k3);

id PG(S(v19?,v2?),p12?)*VQQG(s5?,p5?,s7?,p7?,v2?,p2?)*PQx(s5?,s6?,p56?)*PQx(s7?,s8?,p78?)*VQQG(s8?,p8?,s6?,p6?,v3?,p86?)*PG(S(v3?,v4?),p34?) = Sigma(p34);
*
*        ^
*        |
*       BUG
*
*  The transformation rule above collects a gluon propagator
*  into a simple expression `Sigma(k3+k4)'. The current version
*  works as expected.
*
*  If you, however, change index `v19?' to `v1?' the rule above
*  works not as expected.
*
*  > form -v
*  FORM 4.1 (Jan 13 2014) 64-bits
*
*  > uname -a
*  Linux golf.gituliar.org 3.14.4-1-ARCH #1 SMP PREEMPT Tue May 13 16:41:39 CEST 2014 x86_64 GNU/Linux
*
.sort

Print +sss;
.end

[tueda]

Just a supplement to clarify what the problem is:

CF f,g;
T S(symmetric);
*I v9;  * <-- (1)
I v1,...,v9;

L F1 = f(S(v1,v2)) * g(v1);
L F2 = f(S(v1,v2)) * g(v2);

id f(S(v9?,v1?)) * g(v1?) = 1;

P;
.end

gives

   F1 =
      1;

   F2 =
      f(S(v1,v2))*g(v2);

On the other hand, with enabling line (1), it gives

   F1 =
      f(S(v1,v2))*g(v1);

   F2 =
      1;

So the pattern matcher seems not to look into the symmetric property of functions at a sub-level and just performs the matching depending on whether the pattern is sorted as f(S(v2?,v9?))*g(v2?) or f(S(v9?,v2?))*g(v2?).

If a symmetric function and another function are in the same level:

L G1 = S(v1,v2) * g(v1);
L G2 = S(v1,v2) * g(v2);

id S(v9?,v1?) * g(v1?) = 1;

the pattern matching among arguments of two functions works and both G1 and G2 become 1.

[vermaseren]

The problem is that it does not backtrack into the arguments of functions inside functions. If you declare g before f it first matches the g and then it does what you want (in this example). It is not easy to change this, but I admit that it is very desirable. I may not have a solution very soon, unless I can think of some clever trick. The problem is in the routine MatchFunction as far as I can tell. When this was built it was quite novel and powerful for what people did then. Now we do more complicated things and this was obviously not tried out in those days. There are more open ends in the pattern matcher. There is a whole file which is waiting for some AI code to help in determining that very complicated matches with symmetric functions, ?a,?b,?c etc cannot occur, which might take a long time otherwise when many wildcards are involved and it has to try all combinations. Effectively, the pattern matcher will never be finished, because whatever I construct, I am sure you can come up with something that breaks it.

If you need a quick fix, try to see whether you can work around it by controling the order of declaration of the functions (and/or other variables). I will fix this sooner or later, but maybe that is not soon enough for you.

Jos

On 4 mrt. 2015, at 11:56, Takahiro Ueda <notifications@github.com mailto:notifications@github.com> wrote:

Just a supplement to clarify what the problem is:

CF f,g; T S(symmetric); I v9; \ <-- (1) I v1,...,v9;

L F1 = f(S(v1,v2)) * g(v1); L F2 = f(S(v1,v2)) * g(v2);

id f(S(v9?,v1?)) * g(v1?) = 1;

P; .end gives

F1 = 1;

F2 = f(S(v1,v2))*g(v2); On the other hand, with enabling line (1), it gives

F1 = f(S(v1,v2))*g(v1);

F2 = 1; So the pattern matcher seems not to look into the symmetric property of functions at a sub-level and just performs the matching depending on whether the pattern is sorted as f(S(v2?,v9?))_g(v2?) or f(S(v9?,v2?))_g(v2?).

If a symmetric function and another function are in the same level:

L G1 = S(v1,v2) * g(v1); L G2 = S(v1,v2) * g(v2);

id S(v9?,v1?) * g(v1?) = 1; the pattern matching among arguments of two functions works and both G1 and G2 become 1.

— Reply to this email directly or view it on GitHub https://github.com/vermaseren/form/issues/12#issuecomment-77137755.

[tueda]

The following is another example, which I want to make it work and have no idea to an alternative for now (except writing 3!3!6!/2=432 patterns explicitly without the symmetric function)

V p1,...,p5,SPLIT;
CF vx,R(s),v4;
S n;

L F =
   vx(R(p1,p4,p5),p1,p4,-p5)
  *vx(R(p2,p3,p5),-p2,-p3,p5)
  *v4(R(p1,p2,p3,p4),1);

id vx(R(p1?,p4?,p5?),?a)
  *vx(R(p2?,p3?,p5?),?b)
  *v4(R(p1?,p2?,p3?,p4?),n?)
  = vx(n,?a,?b) * replace_(p5,SPLIT);  * doesn't match

repeat id vx(?a,SPLIT,?b) = vx(?a,?b);
repeat id vx(?a,-SPLIT,?b) = vx(?a,?b);

P;  * hope to get vx(1,p1,p4,-p2,-p3)
.end