New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration result appears to use a different branch of polylog #13850
Comments
I suspect that the integration result is oversimplified at some stage.
|
It's still the same thing, unfrortunately: the relevant piece is |
I think I found the source of this wrong result:
By Wolfram Functions this is Why I think so: I traced the computation step by step. First, meijerint_indefinite shifts the function to
This reads as This is going to be tricky: since x > 1 here, the expression Next, these are integrated.
Here, So the error has to be in |
For a concrete example, take x = 3. The value of
On the other hand, I suspect the issue is in |
Now, the question is, which value should be taken for On the whole, this computation by means of Meijer G-functions is on uncertain basis since it depends on the analytic continuation of the functions to a boundary cut. For example, the expression of |
Upon further reflection, it seems the implementation of Slater's theorem is correct but perhaps its result is being over-simplified. Since we have a G-function with p=q=3, one has to deal with |z|<1 and |z|>1 separately, which is correctly implemented in When reducing
But then it considers whether the region of convergence of G-function is connected and if so, decides that the first formula is universally valid by the uniqueness of analytic continuation. This may be an oversimplification because the second formula had information regarding branch choice that the first one did not. Indeed, evaluating the first formula at x = 3:
Evaluating the second formula at x = 3:
Polylog is unbranched in the unit disk, so the first term is same as As long as polylog and similar functions are concerned, one should probably prefer piecewise formulas that keep the argument within the unit disk to the simpler formulas that end up evaluating on the branch cut. |
After spending quite a lot of time on various G-functions I noticed that the integral can be computed quite easily by partial integration using
This is valid in the domain
This result can be connected to that given by SymPy by means of the reflection formula of dilogarithm:
which is valid in the complement of the real axis (and, in addition, for
where |
The following is close to being correct:
The real part is fine. The imaginary part is (obviously) wrong. Indeed, polylog(2, 2) is
pi**2/4 - I*pi*log(2)
and so we end up with extra2*I*pi*log(2)
.My first guess was that polylog terms comes from somewhere where it's understood to have a different branch cut, equating to
pi**2/4 + I*pi*log(2)
at 2.Or perhaps it's the branching of log that's treated wrong here. The indefinite integral is returned as
This is incorrect; the derivative of that function is
(log(-x) + i*pi) / (x+1)
, which isn't equivalent tolog(x)/(x+1)
, even for positive x.Why SymPy makes this mistake seems related to #13853. From its point of view, the derivative is
-polylog(1, x + 1)/(x + 1) + I*pi/(x + 1)
(correct) which it turns (with current form of expand_func) intoUsing that log(exp_polar(-I*pi)) = - I *pi, we get
log(x + exp_polar(I*pi) + 1)/(x + 1)
which islog(x)/(x+1)
. So the antiderivative seems correct, even though it isn't. Faultyexpand_func
makes a wrong antiderivative appear to be correct.The text was updated successfully, but these errors were encountered: