Dear all, while working on our program handyG [1909.01656] for the numerical evaluation of GPLs, I've noticed that my installation of GiNaC (1.7.7) throws an error for a certain class of GPLs. An example of such a GPL is G(x,y,x; 1.) with x=1/100 + I/8 and y =-1/8 G({x,y,x},1.); map_trafo_H_1mx: cannot handle weights equal -1! I tried to analyse the problem and (probably) traced it back to the evaluation of Li({1,2}, {x/y, 1}) == Li({1,2}, {z, 1}) = H({1,0,1},z) with z = x/y = -2/25 - I which throws the same error. As far as I understand, the HPLs are evaluated as follows (all line numbers refer to inifcns_nstdsums.cpp) * To speed up convergence for some range of values, a transformation x -> 1-x is performed, assuming all weights are positive (otherwise the transformation is not well-defined). This happens in line 3314. * The error is thrown if there are negative weights being transformed (line 2845). * In line 3227-3244, the parameter list m is populated using integers. A bool variable has_minus_one is set to true (3239) should one of weights be negative in order to not attempt the transformation to 1-x * I understand lines 3279-3287 to check whether Re[x] > 0 and to transform to guarantee this if need be. Part of the transformation (line 3283) requires m[i] -> -m[i]. If m[i] used to be positive, this means that m[i] is now negative. * Because has_minus_one does not seem to be re-computed after this re-mapping, it is possible to trip up GiNaC with HPLs. * We need to require the transformation x -> 1-x, i.e. - |x| > 0.95 to avoid direct summation (line 3246), - |x| < 2 to avoid the transformation x->1/x (line 3290), and - |(1-z)/(1+z)| > 0.9 with z = -x. * We need to guarantee that the problematic mapping x->-x occurs, i.e. Re[x] < 0. This results in two rather small regions (measure is just 0.36) just left of the imaginary axis with 1 < |Im[x]|| < 2. * m needs to contain +1 and not have no trailing zeros. A rather trivial fix for this would be just to re-check has_minus_one like so --------------------------------------------------------------------- diff --git a/ginac/inifcns_nstdsums.cpp b/ginac/inifcns_nstdsums.cpp index f040e8ad..c08cd32b 100644 --- a/ginac/inifcns_nstdsums.cpp +++ b/ginac/inifcns_nstdsums.cpp @@ -3300,6 +3300,9 @@ static ex H_evalf(const ex& x1, const ex& x2) // check transformations for 0.95 <= |x| < 2.0 + for (auto const& i : m) { + if (i == -1) has_minus_one = true; + } // |(1-x)/(1+x)| < 0.9 -> circular area with center=9.53+0i and radius=9.47 if (cln::abs(x-9.53) <= 9.47) { // x -> (1-x)/(1+x) --------------------------------------------------------------------- Having applied this patch, the offending HPL discussed above comes out with its correct value of H({1,0,1},z) = -0.25454297772039644317+0.27861285229476603358 I have compared this to Daniel Maitre's HPL [hep-ph/0703052] and find it match. I'm looking forward to your feedback. Cheers, Yannick