Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: simplifying inside sum, Mathematica 5.1

  • To: mathgroup at smc.vnet.net
  • Subject: [mg53762] Re: simplifying inside sum, Mathematica 5.1
  • From: Maxim <ab_def at prontomail.com>
  • Date: Wed, 26 Jan 2005 04:37:34 -0500 (EST)
  • Organization: MTU-Intel ISP
  • References: <ct4h70$av2$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

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


  • Prev by Date: Re: Monte Carlo Simulation Experiences
  • Next by Date: random array of n 2-tuples
  • Previous by thread: Re: Re: simplifying inside sum, Mathematica 5.1
  • Next by thread: Re: Re: simplifying inside sum, Mathematica 5.1