Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

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:

Unprotect[MoebiusMu];  
MoebiusMu[1] := -1  
Protect[MoebiusMu];  

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

So, why does NSum return -1.?

share|improve this question
    
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 en.wikipedia.org/wiki/Mertens_conjecture –  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=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 1

up vote 5 down vote accepted

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]]]

Sample Points

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

share|improve this answer
    
+1, very nice. Since I am applying the analysis to only the $s=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 $$\sum_{k=1}^\infty\frac{\mu(k)}{k^s}=\frac1{\zeta(s)}$$ and take $s\to1$, we get $0$... –  J. M. May 10 '13 at 5:44
1  
@J.M. Did you mean $s \rightarrow 0$? That's what Mathematica is doing with Regularization -> "Dirichlet". And the result is $1/\zeta(0) = -2$. –  Michael E2 May 10 '13 at 10:28
    
@Michael, oops, you're right. –  J. M. May 10 '13 at 11:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.