Another MoebiusMu question

When I evaluate the Mertens function to infinity:

NSum[MoebiusMu[k], {k, 1, \[Infinity]}]

I get -1, but I expected to get -2.

I wanted to modify the function thus:

MoebiusMu[1] := -1

in order to get -2. But that gives me -3.

So, why does NSum return -1.?




If MoebiusMu[1] is changed from 1 to -1, I would expect the sum to decrease by 2. To get it to decrease by 1, you might change MoebiusMu[1] to 0 or consider just subtracting 1 from the sum.
– Michael E2
May 10 ’13 at 4:10



You probably have a good reason for wanting to change the system function, but it does destroy its multiplicativity property. If there are internal rules that rely on the property, I would worry that errors might be introduced.
– Michael E2
May 10 ’13 at 4:23



@MichaelE2 I think the problem isn’t along that line. The Mertens function oscillates badly
– Dr. belisarius
May 10 ’13 at 4:24



@MichaelE2, it is along that line. I am trying to use analytic continuation in the non-negative reals to define Mertens at s=0s=0. Because Mathematica returns -1., I can change to a zero. But I need to know where the -1. comes from so I can explain it. I am working on a question for mathMO which I should post soon, in which I will explain my reasoning. I’ll post a link here when that happens.
– Fred Kline
May 10 ’13 at 4:36



@FredKline I see. I misunderstood.
– Michael E2
May 10 ’13 at 4:45


1 Answer


In short NSum cannot handle this sort of sequence. Indeed, strictly the series is not convergent, and some notion of summability/regularization needs to be chosen.
Given the nature of MoebiusMu, “Dirichlet” seems appropriate:

Sum[MoebiusMu[k], {k, 1, \[Infinity]}, Regularization -> “Dirichlet”]
(* -2 *)

Here’s how one can see NSum is not working reliably.
From the NSum reference page:

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.

The default for NSumTerms is 15. Here’s what happens if we increase that:

Quiet@NSum[MoebiusMu[k], {k, 1, \[Infinity]}, NSumTerms -> #] & /@ Range[15, 30]

(* {-1., -1., -1., ComplexInfinity, ComplexInfinity, -4., -4.,
ComplexInfinity, ComplexInfinity, -1., -1., -1.5, ComplexInfinity,
0., 0., ComplexInfinity} *)

You get all sorts of answers. Quiet is suppressing the warning

NSum::nsumz: Some terms are zero. The algorithms are not very applicable. >>

One can see which terms are being tested this way:

ListPlot[Reap[NSum[MoebiusMu[k], {k, 1, Infinity}, EvaluationMonitor :> Sow[k]]][[2, 1]]]

The NSum reference page
suggests this is typical of the sequence extrapolation method. MoebiusMu is not well-suited for extrapolation from these points.



+1, very nice. Since I am applying the analysis to only the s=0s=0 situation, I can define MoebiusMu as I see fit (assuming I can prove it.)
– Fred Kline
May 10 ’13 at 5:36



On the other hand, if we take the well-known identity ∞∑k=1μ(k)ks=1ζ(s)\sum_{k=1}^\infty\frac{\mu(k)}{k^s}=\frac1{\zeta(s)} and take s→1s\to1, we get 00…
– J. M.♦
May 10 ’13 at 5:44



@J.M. Did you mean s→0s \rightarrow 0? That’s what Mathematica is doing with Regularization -> “Dirichlet”. And the result is 1/ζ(0)=−21/\zeta(0) = -2.
– Michael E2
May 10 ’13 at 10:28



@Michael, oops, you’re right.
– J. M.♦
May 10 ’13 at 11:01