Re: Re: simplifying inside sum, Mathematica 5.1

*To*: mathgroup at smc.vnet.net*Subject*: [mg53785] Re: [mg53762] Re: simplifying inside sum, Mathematica 5.1*From*: DrBob <drbob at bigfoot.com>*Date*: Thu, 27 Jan 2005 05:41:24 -0500 (EST)*References*: <ct4h70$av2$1@smc.vnet.net> <200501260937.EAA00268@smc.vnet.net>*Reply-to*: drbob at bigfoot.com*Sender*: owner-wri-mathgroup at wolfram.com

Maxim, As usual, your analysis is broader and deeper than mine (or anyone else's, maybe) and the implications seem devastating for using Sum at all. I don't use it often, in fact, because of issues I never understood, possibly related to the ones you've mentioned. (I use it so seldom, I don't entirely remember why!) Your delineation of these strange behaviors is very useful; it helps to know what to look out for. Bobby On Wed, 26 Jan 2005 04:37:34 -0500 (EST), Maxim <ab_def at prontomail.com> wrote: > Mathematica does use some implicit assumptions about the iteration bounds: > > In[1]:= > Sum[1, {k, 1/2, n}] > > Out[1]= > 1/2 + n > > This assumes that the sum is taken over the points k = 1/2, 3/2, ..., n; > that is, when evaluating Sum[f[k], {k, a, b}] symbolically Mathematica > assumes that (b-a) is integer. For a value of n such that (n-1/2) is not > integer (say n=5) Out[1] would be incorrect in the sense that Sum[1, {k, > 1/2, 5}] does not equal 1/2 + 5. > > So if we take > > In[2]:= > Sum[Sin[Pi*k]^2, {k, n}] > > Out[2]= > (1 + 2*n - 2*I^(2*n)*n*Cos[n*Pi] - Cos[2*n*Pi])/4 > > the result again doesn't hold for an arbitrary non-integer n (Out[2] can > be complex), and since n is assumed to be integer, Mathematica indeed > could have simplified the summand by doing Refine[Sin[Pi*k]^2, Element[k, > Integers]] to obtain 0 immediately. > > What seems to be the real problem is that Mathematica doesn't handle those > implicit assumptions in a consistent way: > > In[3]:= > Sum[Cos[Pi*k], {k, 1/2, 2*n}] > > Out[3]= > 1 > > In[4]:= > Sum[UnitStep[1 - k], {k, 1/2, Infinity}] > > Out[4]= > 3/2 > > In[5]:= > Sum[Sqrt[k], {k, 1/2, n + 1/2}] > > Out[5]= > HarmonicNumber[1/2 + n, -1/2] > > It is easy to verify that Out[3] is incorrect for any value of n (again, > in the sense that if we substitute any numerical value for n before > evaluating the sum, we will obtain 0, not 1), Out[4] cannot be correct > because a sum of UnitStep terms cannot be half-integer, and Out[5] may > happen to be correct for some values of n, but not for integer n. > > Next, what if we take a sum from a to b with a>b? > > In[6]:= > Sum[1, {k, Infinity, 1}] > > Out[6]= > -Infinity > > In[7]:= > Sum[1/k^2, {k, Infinity, 1}] > > Out[7]= > Pi^2/6 > > In[8]:= > Sum[1/(k^2 + 1), {k, Infinity, -Infinity}] > > Out[8]= > 0 > > Out[6] can be justified if we assume > > Sum[f[k], {k, a, b}] == -Sum[f[k], {k, b, a}]. > > Out[7] is fine under the assumption > > Sum[f[k], {k, a, b}] == Sum[f[k], {k, b, a}]. > > Out[8] is valid if we agree that > > Sum[f[k], {k, a, b}] == 0 provided that a>b. > > Each of these three conventions makes sense and can be useful. However, it > is impossible to reconcile all three answers with one another (I prefer > the third case, again because it agrees with numerical summation). We > should choose one and only one convention and stick to it, otherwise it's > just as good as returning a random result. > > Finally, the general form of the iterator is {k, a, b, d}: > > In[9]:= > Sum[1/k^2, {k, Infinity, 1, -1}] > > <Infinity::indet warning> > > Out[9]= > Indeterminate > > Even in these trivial examples we can see that Mathematica simply doesn't > have a clear definition of how a symbolic sum is understood in such cases, > and consequently, doesn't have a consistent implementation either. > > Maxim Rytin > m.r at inbox.ru > > > > -- DrBob at bigfoot.com www.eclecticdreams.net

**References**:**Re: simplifying inside sum, Mathematica 5.1***From:*Maxim <ab_def@prontomail.com>