MathGroup Archive 2009

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

Search the Archive

Re: Re: error with Sum and Infinity

  • To: mathgroup at smc.vnet.net
  • Subject: [mg102457] Re: [mg102437] Re: error with Sum and Infinity
  • From: George Woodrow III <georgevw3 at mac.com>
  • Date: Sun, 9 Aug 2009 18:22:01 -0400 (EDT)
  • References: <h5bk64$hlm$1@smc.vnet.net> <200908070932.FAA15211@smc.vnet.net>

Also including a private response from Richard:

[me]
> You can get the performance you want by using Piecewise[]. That way,  
> there is only one function definition.
>
[Richard]
Yes, one can often get the predetermined right answer by asking a  
subtlely different question.  Still, I think you agree the answer to  
the original question was wrong...

[my comment]
The point to this is that yes, the original 'naive' attempt at a sum  
gave the wrong answer. The wrong answer should have prompted a journey  
to find out why.

The reason why the first attempt gave the wrong answer is that the  
question was ill-posed for Mathematica to "always" do the right thing.  
My solution (using Piecewise) and another poster's solution using  
DiracDelta posed the question in a way that when Mathematica switched  
from brute force (below SymbolicSumThreshold) to symbolic, it would do  
the right thing.

You get this type of thing all the time. What would you want  
Mathematica to do with a finite sum of {1, -1, 1, -1, ..... 1, -1}? It  
should give 0 in this case. However, for an infinite sum, you'd want  
it to fail, as it does.

(forgive the quick and dirty way to get a sequence of 1,-1.)

t[x_] := Cos[Pi x]

In[21]:= u = Table[t[a], {a, 0, 100}]
Out[21]= {1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1,  
-1, 1, -1, 1, -1, \
1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1,  
1, -1, \
1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1,  
1, -1, \
1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1,  
1, -1, \
1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1, -1, 1}

In[22]:= Sum[t[a], {a, 100}]
Out[22]= 0

In[18]:= Sum[t[a], {a, 10000000}]
Out[18]= 0

In[23]:= Sum[t[a], {a, 10000001}]
Out[23]= -1

In[24]:= Sum[t[a],{a,Infinity}]
During evaluation of In[24]:= Sum::div: Sum does not converge. >>
Out[24]= \!\(
\*UnderoverscriptBox[\(\[Sum]\), \(a\), \(\[Infinity]\)]\(Cos[a\ \[Pi]] 
\)\)

The point of this is to show that you need to know some maths, and at  
least a little bit about the conventions of Mathematica. An infinite  
sum cannot be treated the same as a finite sum, and care needs to be  
taken to be sure that Mathematica knows what the sequence really is.

In the case of a sequence of all 0, except for a single 1, then the  
function that defines the sequence needs to make the exception clear  
in the definition.

Could Mathematica be designed to always give the right answer, not  
matter what the input? Perhaps. Most of the time, it would be a waste  
of time.

The proper lesson to learn is that if you are going to be evaluating  
infinite sums, then it would be worth finding out how Mathematica does  
this and what needs to be done to make the code fool-proof.

In this case, one could learn that Mathematica will sometimes ignore  
exceptional cases (separate definitions of the function at special  
values) when computing sums, and if you want these cases to be  
included in an infinite sum, you need to define the function so that  
these cases are handled symbolically.

You can be upset that mathematica does not do exactly what you expect  
all the time, but it does no good to rant about it. The fact is, there  
are well documented ways to deal with this problem so that mathematica  
*does* do the right thing, not just in this toy example, but in more  
complex problems. Every language has its way of interpreting code.  
Mathematica is special in that there are a lot more ways to get the  
code 'almost' right and usually a lot of different ways to get the  
code exactly right. A similar coding error in c would simply give a  
compiler error or crash.

As for your gratuitous comment about Andrzej's post, I think that  
anyone familiar with any type of computer algebra system would be able  
to guess, just in terms of practicality, that there is a threshold  
from brute force to symbolic summation. Otherwise, Mathematica could  
never compute an infinite sum. I have been using Mathematica for 20  
years, and I did not know the name for the threshold, let alone its  
value, but for my purposes, I did not need to know. However, I did  
know (and it was in the documentation) that there is a point where one  
type of computation ends and another begins.

The function SystemOptions[] is defined and documented in version 7  
(It was new in version 6).

If you execute SystemOptions["*"], you get an impressive list of all  
the options and their current values. Most appear to be self- 
explanatory, but a few look like more explanation is needed. It also  
appears that if your code depends on the values for these options, the  
code may be fragile at a minimum.

Note that the original problem had a resolution that did not involve  
special knowledge of these variables. I'd say that knowing that these  
options exist belongs to advanced users of Mathematica. It might be  
nice to have more complete documentation for some of these options --  
and Tech Support has provided this information when I have needed it,  
but this knowledge would not have solved the original question.

george

On Aug 9, 2009, at 6:06 AM, Richard Fateman wrote:

> Andrzej Kozlowski wrote:
>> On 8 Aug 2009, at 02:16, Richard Fateman wrote:
>>
>> <attempt at humor snipped>
>>
>> he or she can
>> always evaluate
>>
>> "SymbolicSumThreshold" /. SystemOptions[]
>> 1000000
>>
>> which, I think, deals with the rest of your post.
>>
>> Andrzej
>
> I assumed there was some name for that magic number, and now you  
> tell me
> this is the name. Thanks.
>
> 1. In the Alphabetical List of functions and other objects in
> Mathematica, available as guide/AlphabeticalListing in the online  
> manual
> for version 6.0,  there is no appearance of SymbolicSumThreshold.
> Options[Sum] returns {}  On the plus side, searching  via  ? *Sum*
> reveals the presence of Global`SymbolicSumThreshold but with no
> information on it.
>
> 2. I assume you are implicitly agreeing with me that it is
> unsatisfactory to require any user to guess at the existence, name,  
> and
> effect of an undocumented global flag. But you can't bring yourself to
> say so.
>
>
> RJF
>



  • Prev by Date: Re: Re: error with Sum and Infinity
  • Next by Date: Re: Highlighting data sections with a different
  • Previous by thread: Re: Re: error with Sum and Infinity
  • Next by thread: Re: Re: Re: error with Sum and Infinity