Code review comment for lp:~maddevelopers/mg5amcnlo/2.6.3_optimizenlomodel

Mhh, It may be nice to cover K=-1 too no?

Nice yes, but quite heavy.
(ALOHA itself will be quite slow for such task,
 yacc and lex are a fast enough solution but quite heavy to implement.
regular expression might be easy enough but quite slow.

The best would be that such identification be part of the UFO model and not something that we have to discover...

This is quite hard since you have case like
a/(b+c) + c + (d+ e)/f
and the opposite
-a/(b+c) - c + (d+ e)/(-f)
(ok I'm slightly complexify what we will face but the problem is there)

Cheers,

Olivier

On 12 Jun 2018, at 22:27, Valentin Hirschi <<email address hidden><mailto:<email address hidden>>> wrote:

Hi,

On Tue, Jun 12, 2018 at 10:00 PM, Olivier Mattelaer <
<email address hidden><mailto:<email address hidden>>> wrote:

Hi,

To be complete I detect K=1
only if it is analytically 1 (and trivially so, i.e. if both use the same
name

Mhh, It may be nice to cover K=-1 too no?

The case K=+/-1 is tackle ONLY for restricted model and the comparison is
done numerically.
I would not like to pass to numerical comparison for ALL integer since it
is too dangerous to have false positif.
Also doing K=+/-2 differs from the actual description of the
restrict_model (but thate

I agree completely here, such false positive would be really hard to track
down.

Now it would make sense to look at the K as any integer at the analytical
level.
But I'm slightly worried about the time impact (at the same time this is
only the first time since it is save in the pkl). I think i will test
something with string comparison:

something like:

couplings.order(key=len)
for i in range(len(couplings)):
       for j in range(i+1, len(couplings))
               c1, c2 = couplings[i], couplings[j]
               c2.expr = c2.expr.replace(str(c1), c1.name)

Then a simple regular expression should be able to detect case where

c2.expr=" 2 * GC_1"

What do you think?

That could work I suppose, but I think that in practice it makes very
little difference because most of the model will benefit from
simplifications where K is -1 or 1.
So in my opinion, it's not worth the effort:

PS: checkout sympy, it's nice to keep that option in mind for possible
future applications one day (though for anything heavy, it would be better
to wait for the upcoming python bindings of the new version of FORM).

Cheers,

Cheers,

Olivier

On 12 Jun 2018, at 16:31, Valentin Hirschi <<email address hidden><mailto:<email address hidden>>>
wrote:

Nevermind, I worked it out again and realised what you did is basically
the best you can get already. In general, if you have this interaction:

particles = [p.A, p.B, p.C]
color = ['C1','C2']
lorentz = [L.LA, L.LB, L.LC]
couplings = {
(0,0): C.G1, (0,1): C.G2, (0,2): C.G3,
(1,0): C.G4, (1,1): C.G5
}

you can generalise your procedure by defining the following two Lorentz
structure being basically:

L.LA + (C.G2/C.G1)*L.B + (C.G3/C.G1)*L.C

and

L.LA + (C.G5/C.G4)*L.B

But I now realise that it's pointless/hard to do this if
(C.G<i>/C.G<j>)=K , with K having model parametric dependence. You
implemented this for K= +/-1, and in principle it could be extended to any
integer, but that has very little value in practice indeed.
So I agree, what you did is already basically the best you can get
already.

Cheers

--
https://code.launchpad.net/~maddevelopers/mg5amcnlo/2.6.3_
optimizenlomodel/+merge/346864
Your team MadDevelopers is subscribed to branch
lp:~maddevelopers/mg5amcnlo/2.6.3_optimizenlomodel.

--
https://code.launchpad.net/~maddevelopers/mg5amcnlo/2.6.3_
optimizenlomodel/+merge/346864
You are reviewing the proposed merge of lp:~maddevelopers/mg5amcnlo/2.6.3_optimizenlomodel
into lp:~mg5core2/mg5amcnlo/2.6.3.

--
Valentin

https://code.launchpad.net/~maddevelopers/mg5amcnlo/2.6.3_optimizenlomodel/+merge/346864
Your team MadDevelopers is subscribed to branch lp:~maddevelopers/mg5amcnlo/2.6.3_optimizenlomodel.