[GiNaC-devel] Evaluation of generalised and harmonic polylogarithms
Yannick Ulrich
yannick.ulrich at psi.ch
Fri Oct 4 15:01:08 CEST 2019
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
More information about the GiNaC-devel
mailing list