[GiNaC-devel] Evaluation of generalised and harmonic polylogarithms

[Yannick Ulrich]

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