Hi,

On Tue, Jun 12, 2018 at 10:00 PM, Olivier Mattelaer <
<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>
> 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