# Incorrect value of infinite sum

Wolfram Alpha and Mathematica give an incorrect result (numerically) for the following infinite sum:

N[Sum[((-1)^n)/(n - (-1)^n), {n, 1, Infinity}]]
(* 0.700059 *)


Here's the result on Wolfram Alpha. Why the series isn't correctly evaluated?
The answer should be $\log(2)$.

-

From NSum:

You should realize that with sufficiently pathological summands, the algorithms used by NSum can give wrong answers. In most cases, you can test the answer by looking at its sensitivity to changes in the setting of options for NSum.

For instance:

NSum[((-1)^n)/(n - (-1)^n), {n, 1, Infinity}, NSumTerms -> 100000]

(* 0.693149 - 5.15666*10^-7 I *)


which is closer to Log[2] = 0.693147….

Aside

One can do the sum in Mathematica if the partial sum is found by summing the odd and even parts separately:

Sum[((-1)^n)/(n - (-1)^n) /. n -> 2 k, {k, 1, n0}] +
Sum[((-1)^n)/(n - (-1)^n) /. n -> 2 k - 1, {k, 1, n0}] // FullSimplify

(* 1/2 (HarmonicNumber[-(1/2) + n0] - HarmonicNumber[n0] + Log[4]) *)

Limit[1/2 (HarmonicNumber[-(1/2) + n0] - HarmonicNumber[n0] + Log[4]), n0 -> Infinity]

(* Log[2] *)


More succinctly and quicker (along the lines of A.G.'s comment):

Sum[((-1)^n)/(n - (-1)^n), {k, 1, Infinity}, {n, 2 k - 1, 2 k}]

(* Log[2] *)


These two are mathematically equivalent, since the partial sums are sums of an even number of terms of the original series. As alluded to in a comment, it is valid because the n-th term approaches zero, which implies the difference between consecutive partial sums of the original series approaches zero. Contrast with Euler's counterexample, Sum[(-1)^n, {n, 1, Infinity}].

-
@Chris'ssis Michael is citing the help ... –  belisarius Dec 23 '13 at 17:17
@Chris'ssis No problem. I think what seems "pathological" to us and what is "pathological" to NSum's algorithms might not be the same thing. –  Michael E2 Dec 23 '13 at 17:22
Quiet@NLimit[ NSum[((-1)^n)/(n - (-1)^n), {n, 1, Infinity}, NSumTerms -> m], m -> Infinity] - Log@2 –  belisarius Dec 23 '13 at 17:32
Increase the WorkingPrecision in NSum will elimimate the imaginary part. –  Silvia Dec 24 '13 at 4:14
You can also pair up consecutive terms of the sum: Limit[Sum[1/(2 k - 1) - 1/(2 k), {k, 1, n/2}], n -> Infinity] returns Log[2]. –  A.G. Dec 24 '13 at 4:56

For Nsum several options for the method of summation is allowed, with Method -> Automatic by default. If to put explicitly Method -> "AlternatingSigns" it gives the result, though to get three true digits one has to take a very high PrecisionGoal:

NSum[((-1)^n)/(n - (-1)^n), {n, 1, Infinity},
PrecisionGoal -> 10^4, Method -> "AlternatingSigns"]


0.6930394027669343

On the other hand setting Method -> "WynnEpsilon" gives a wrong answer almost as in the question:

NSum[((-1)^n)/(n - (-1)^n), {n, 1, Infinity},
PrecisionGoal -> 10^4, Method -> "WynnEpsilon"]


0.7015171756747272

Increasing WorkingPrecision and changing other parameters doesn't seem to help. So perhaps in this case not the best method is taken automatically.

-
You can also increase NSumTerms and WorkingPrecision with the "AlternatingSigns" method to help get closer to the true value. –  Michael E2 Dec 23 '13 at 17:53
@MichaelE2 I tried but strangely it didn't help. Perhaps this example is "pathological" in some sense for the methods used. –  Andrew Dec 23 '13 at 18:05
I guess you're right. I tried "AlternatingSigns" at first and the result was worse with the default options (I think because the absolute values of the terms are non-decreasing). You have to get NSumTerms pretty large before there's a sufficient improvement, 10^4 or 10^5. Probably PrecisionGoal also affects how many terms are used. It seems like it ought to. So in effect, they're similar. –  Michael E2 Dec 23 '13 at 18:22
@Andrew Thanks for answer (+1) –  Chris's sis Dec 23 '13 at 21:43