0

While doing certain computations involving the Rogers L-function, the following result was generated by Wolfram Alpha:

                               enter image description here

I wanted to verify this result in Pari/GP by means of the lindep function, so I calculated the integral to 20 digits in WA, yielding:

11.3879638800312828875

Then, I used the following code in Pari/GP:

lindep([zeta(2), zeta(3), 11.3879638800312828875])

As pi^2 = 6*zeta(2), one would expect the output to be a vector along the lines of:

[12,12,-3]

because that's the linear dependency suggested by WA's result. However, I got a very elaborate vector from Pari/GP:

[35237276454, -996904369, -4984618961]

I think the first vector should be the "right" output of the Pari code sample.

Questions:

  1. Why is the lindep function in Pari/GP not yielding the output one would expect in this case?
  2. What can I do to make it give the vector that would be more appropriate in this situation?
Max Muller
  • 341
  • 1
  • 3
  • 10

2 Answers2

2

  1. It comes down to Pari treating your rounded values as exact. Since you must round your values, lindep's solution doesn't always come to the same solution as the true answer due to error.

  2. You can try changing the accuracy of lindep using the second argument. The manual states that you should choose this to be smaller than the number of correct decimal digits. I believe this should solve the issue.

lindep(v, {flag = 0}) finds a small nontrivial integral linear combination between components of v. If none can be found return an empty vector.

If v is a vector with real/complex entries we use a floating point (variable precision) LLL algorithm. If flag = 0 the accuracy is chosen internally using a crude heuristic. If flag > 0 the computation is done with an accuracy of flag decimal digits. To get meaningful results in the latter case, the parameter flag should be smaller than the number of correct decimal digits in the input.

Punchinello
  • 38
  • 4
2

Let PARI do the whole work for you:

? A = intnum(x = 0, 1, (log(1-x)/x + log(x)/(1-x))^2);
? lindep([zeta(2), zeta(3), A])
%2 = [-4, -4, 1]~

As mentioned in Punchinello's answer your problem comes from using a rounded value (to 20 significant digits) whereas lindep expects the results to be correct to the current default accuracy (which is 38 on startup). Indeed, if we take your input at face value, the output vector is a "better" relation than the expected one:

 ? B = 11.3879638800312828875; A - B
 %3 = -1.1386687370099280047 E-20
 ? v = [35237276454, -996904369, -4984618961]~;
 ? [zeta(2), zeta(3), B] * v
 %5 = 1.6774134320743941085 E-21
 ? [zeta(2), zeta(3), B] * [-4, -4, 1]~
 %6 = 1.1386687370099280047 E-20

Whereas intnum gives me a more precise value, for which the expected relation holds to at least 37 decimals. We can in fact easily check it to a much larger accuracy (but not obtain a proof, of course):

 ? [zeta(2), zeta(3), A] * [-4, -4, 1]~
 %7 = 0.E-37
 ? \p1000   
 realprecision = 1001 significant digits
 ? A2 = intnum(x=0,1, (log(1-x)/x+log(x)/(1-x))^2);
 time = 1,290 ms.
 ? [zeta(2),zeta(3),A2] * [-4, -4, 1]~
 %9 = 2.378452118639963615 E-1001
K.B.
  • 861
  • 5
  • 14