# Sum and NSum gives different solutions

I'm working on a Mathematica lab for Calc. 2, and I ran into a problem last night. I was trying to calculate the midpoint approximation of the definite integral of Cos[x] from 0 to 2. Here's what I came up with:

Clear[a, b, n, f]

f[x_] = Cos[x]

a := 0; b := 2; n := 578

N[((b - a)/n)*Sum[f[a + (i - (1/2))*((b - a)/n)], {i, 1, n}]]

0.909298


This is fine, but if I try to use NSum instead of N[...Sum[...]] then this happens:

Clear[a, b, n]

a := 0; b := 2; n := 578

((b - a)/n)*NSum[f[a + (i - (1/2))*((b - a)/n)], {i, 1, n}]


During evaluation of In[35]:= SequenceLimit::seqlim: The general form of the sequence could not be determined, and the result may be incorrect. >>

During evaluation of In[35]:= SequenceLimit::seqlim: The general form of the sequence could not be determined, and the result may be incorrect. >>

35.538

According to the documentation, Sum evaluates the given sum (http://reference.wolfram.com/mathematica/ref/Sum.html), and the N function gives the numerical value of the parameter (http://reference.wolfram.com/mathematica/ref/N.html). Also, NSum should give the numerical approximation of the sum. To my understanding, N[Sum[...]] Should be the same as NSum[...], or am I missing something?

It's not a huge deal as far as typing more, but I'd just like to know why it doesn't work as expected. I've read online that NSum apparently tries to work out part of the sum symbolically, but even if it does I don't see how it could be THAT much different from the real answer.

-
Its probably roundoff errors... ((b - a)/n)*Sum[f[a + (i - (1/2))*((b - a)/n)], {i, 1, n}] // N works. – chris Mar 25 '13 at 19:35
Yes, that does work. That's the same as the first code block that I posted above, but I just don't understand how they could be that much different. The second block above seems to work where n < 159 . Once n gets any bigger you get those warnings and the values get sporadic. – Caleb1994 Mar 25 '13 at 19:47
ok then this works: ((b - a)/n)* NSum[f[a + (i - (1/2))*((b - a)/n)], {i, 1, n}, NSumTerms -> 1000] – chris Mar 25 '13 at 19:58
You're missing the fact that N[Sum[...]] computes the sum exactly and then converts it to floating point output, whereas NSum[...] attempts, through various numerical mechanisms, to approximate the sum (and might not even actually calculate all the terms in the sum in doing so). As the help notes, it can be fooled and needs judicious application of appropriate options to work well. It sounds like you are attempting to use NSum[...] where you really want something like Total@N@Table[...], especially if you're experimenting with Riemann integration. – whuber Mar 25 '13 at 20:09
as @whuber said, you probably want to use Total@Table[]. – acl Mar 25 '13 at 21:28

The crucial point is that N@Sum is not NSum.

## What N@Sum is

N@Sum will first try to evaluate the sum symbolically and then approximate it numerically. Only if Sum cannot perform the first task, and then returns (at least partially) unevaluated, N will resort to using NSum. In case of a finite sum, Sum will always return an evaluated result, consisting possibly of a sum (Plus) of all the terms.

In this example you can see the first situation described: the sum is simplified to \[Pi]^2/6 and then N approximates it:

N@Sum[1/n^2, {n, 1, \[Infinity]}] // Trace


In the following example instead, Sum is not able to find an explicit formula, and in the trace you can see that N is called with the unchanged sum as the argument:

N@Sum[Log[n]/(1 + n^2), {n, 1, \[Infinity]}] // Trace


You can even check that NSum is called by blocking it (I thank L. B. Shifrin for the inspiration):

Block[{NSum},
Hold@Evaluate@N@Sum[Log[n]/(1 + n^2), {n, 1, \[Infinity]}]
]


## What NSum is

As the Documentation Center clearly states, NSum tries to approximate the result by various summation methods (listed under More Information).

The guide also states that:

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.

To get a better sense of this distinction, I think it's useful to check the evaluation

## Experimenting

This code shows you at which points f is called:

f[x_] := (Sow[x, "f"]; Cos[x])
a = 0; b = 2; n = 578;
Reap[NSum[f[a + (i - (1/2))*((b - a)/n)], {i, 1, n},
EvaluationMonitor :> (Sow[i, "i"])],
{"f", "i"}][[2]];
Print["f[] has been called at: ", %[[1, 1]]]
ListPlot[%%[[2, 1]], PlotRange -> All, PlotLabel -> "Evaluation points"]


As you can see, f has been called 8 times and NSum performed 39 evaluation cycles. This clearly indicates that not all 578 points have been taken in consideration.

On the other hand, if you write

f[x_] := (Sow[x, "f"]; Cos[x])
a = 0; b = 2; n = 578;
Reap[Sum[N@f[a + (i - (1/2))*((b - a)/n)], {i, 1, n}], "f"][[2, 1]] // Short
% // Length


you can see that a long list of exactly 578 evaluation is generated.

## Conclusion

What you really need to do is

Sum[N@f[a + (i - (1/2))*((b - a)/n)], {i, 1, n}]

-
That makes a lot of sense. Thank you! Great, detailed answer. – Caleb1994 Mar 25 '13 at 21:44
@Caleb1994 This question mathematica.stackexchange.com/questions/17028/… is closely related to your problem. – Artes Mar 25 '13 at 22:06
Very nice analysis! (+1) – whuber Mar 25 '13 at 22:28
@whuber One should however be careful not to overstate the differences between Sum and NSum. According to the documentation for Sum (under "Properties"): Applying N to an unevaluated sum effectively uses NSum – Jens Mar 28 '13 at 3:16