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>
- Re: simplifying inside sum, Mathematica 5.1