Mathematica 9 is now available
Services & Resources / Wolfram Forums / MathGroup Archive
-----

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: [mg102443] Re: [mg102437] Re: error with Sum and Infinity
  • From: Richard Fateman <fateman at cs.berkeley.edu>
  • Date: Sun, 9 Aug 2009 18:19:26 -0400 (EDT)
  • References: <h5bk64$hlm$1@smc.vnet.net> <200908070932.FAA15211@smc.vnet.net> <29EAD82D-4D06-4036-923E-97DD7B2EDC46@mimuw.edu.pl> <4A7C6176.9060002@cs.berkeley.edu> <h5jdik$18j$1@smc.vnet.net> <200908091006.GAA16013@smc.vnet.net> <99330D0E-4701-4243-BC10-B5A0E9242C03@mac.com>

George Woodrow III wrote:
> 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.

Advising the user to read the manual is so common that there is a 
heavily-used acronym for it (RTFM). But in this case the manual probably 
does not provide enough guidance about what Sum does.

>
> 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. 

You and I know that Mathematica didn't do the right thing. But there was 
no way for a user to determine if the problem was ill-posed in terms of 
Mathematica.  Indeed, I can think of a technique that would allow 
Mathematica to solve such problems, and I have no reason to believe, a 
priori, that Mathematica does not have that technique. Furthermore, 
Mathematica may have such a technique in some future version.
In particular, if Mathematica does not apparently intend to distinguish 
between a mathematical function composed of Sin Cos Pi + - *   and a 
user-defined pattern-driven computer subroutine f[x_]:=If[ ...],  then 
it should work regardless of how the expression is conveyed. The problem 
is WELL FORMED!

> 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.

Another solution would be to do the problem in your head, and write down 
the answer, since it was obvious.  This is making excuses for 
Mathematica, don't you think? 
<snip.. example>

> 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.

But in addition to knowing some maths, you also need to know things 
about Mathematica that it had no business expecting you to know.
That's what I object to here.

>
> 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.

Should you make an excuse for Mathematica getting the wrong answer, even 
if it could, with some slight amount of additional cleverness get the 
right answer? No, I think you should make a fuss. Maybe just a slight 
amount of fuss, but some fuss.  To show that you are paying attention. I 
make a fuss because I know that the program can be written properly.  
You think it would be a waste of time to write the program properly. 
That's a fundamental disagreement between us. I elaborate further below.

>
> 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.

No, I think the lesson is that Mathematica documentation does not 
describe what it does with functions that are not "closed form" in 
infinite summations or even "large summations with SumThresholdWhatever 
terms", and that there is nothing you can do about such undocumented 
"features" except try to program around them (and in my case,  also 
complain).  Note that the default values or even the existence of 
SystemOptions can change without notice from version to version, and so 
you cannot possibly "find out" about such things all the time.  It is 
simply a bad idea for Mathematica to behave this way, and for you to 
make the excuse that the user of Mathematica is responsible for making 
his code fool-proof in the light of this design is to place an enormous 
and largely unnecessary burden on someone who has paid good money for 
this program.

I believe that Stephen Wolfram's perspective on this is that no one 
should believe the result of a computer calculation without independent 
verification, and therefore it is acceptable to take shortcuts which 
work most of the time. But not always. This is apparently OK for (some) 
physicists. It is generally unacceptable to computer scientists who do 
research in this area.  It should be unacceptable to mathematicians, 
except perhaps those who were trained by physicists.


>
> 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 could learn it, but mostly by treating Mathematica, the computer 
program, as though it were a dead frog, and you were a curious child. 
You wonder if a frog, which lives in the water, breathes with gills or 
lungs.  So you dissect it.  The advantage of a computer program over a 
corpse is that you can get any number of fresh corpses to dissect, and 
so you can come to learn all kinds of things.  Unfortunately, some of 
the things you learn may be incorrect generalizations from specific tests.

I would prefer that Mathematica behave in a predictable, documented, and 
mathematically consistent way, and that I not be required to poke it and 
check that my programs still work when I install a new version, or when 
I run the program with different input parameters that might, unknown to 
me, exceed some threshold that I never heard of.

>
> 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. 

It depends on your expectation being reasonable or not, don't you think?

> 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.

Although I have hardly touched the vast array of contributions from 
users, I suspect that your claim is not true for this case or for some 
of the more complex problems. Where is it documented (much less "well 
documented") that sums above 1000000  [or whatever] are different from 
below that?

> 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.

This is true, but Mathematica has some pretense to doing mathematics, 
and you are blaming the user for making a programming error when there 
is nothing wrong with the program.  The error is that Mathematica is not 
correctly  interpreting the code, which is both legal, perfectly clear, 
and unambiguous, by taking a shortcut that is incorrect.  Think about 
what you are saying.  If a C programmer used a compiler and found that 
it sometimes took a correct program and ran it incorrectly, would he 
say, oh, I can write a different program that gets the right answer?  
This is why I view Mathematica, from a computer science/ programming 
language perspective as, how shall we say,... disappointing.

So what is the issue?

1. WRI does not define what its way of interpreting code really is, and 
reserves the right to change it, anyway.
2. The Mathematica user is dependent on the good will  of the 
implementation programmers and, to some extent, luck, for his program to 
work.
3. While guided by mathematics generally, the computer system 
programmers deliberately take shortcuts that violate 100% correctness.

You are, of course, free to try to use Mathematica to solve problems, 
and it may work just fine most of the time.  But as a computer scientist 
who is familiar with mathematics generally, and quite familiar with 
computer algebra systems, I find it unfortunate that you (and others) 
make excuses for Mathematica getting incorrect answers, even when other 
computer programs might get them right, (and WRI may be convinced to fix 
the issues too) thinking that somehow the USER is at fault.


>
> 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.

Why can't Mathematica figure out that the summand is defined in a 
peculiar way and has to be handled carefully?  Why does the user have to 
think about whether the summation is done by brute force or by closed 
formula?  What if the user is building a package and does not know what 
the user of his package has done to define a program that is, 
eventually, used as a summand?  The package-builder must do the analysis 
that WRI should have done in the first place, or else that package may 
fail mysteriously.  This means the package writer must violate a precept 
of the WRI way, which is that a Mathematica user need not be concerned 
about the details of algorithms.  Maybe you THINK you know about how to 
do summation, but do you know how Mathematica does it?  Does your 
knowledge extend to do (say) polynomial factorization?  Are you expected 
to know which classes of polynomials are hard to factor and therefore 
you should not ask Mathematica to factor them?

> 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.

This is true.  In fact I may have used SystemOptions[] at some point in 
the distant past (1984?) but did not connect it to Sum since there is no 
indication in the documentation for Sum that it depends on this 
threshold option.  So there is no way, other than poking at the corpse, 
for you to tell if your code is fragile.

>
> Note that the original problem had a resolution that did not involve 
> special knowledge of these variables. 

Sure, there are lots of resolutions, including, as I said, the excellent 
one of the user just figuring out the answer.  Face it, Mathematica got 
the wrong answer to a problem that is entirely well-posed.  Stop making 
excuses!

> 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.

That is because the original problem was well posed, and Mathematica 
should have solved it!.  Can you not conceive of a programming solution 
to the original problem, or at least a solution that determined whether 
this was a case that might lead to an error?  {It might require going 
slightly outside the usual Mathematica techniques -- I don't know 
offhand how to decompose a function definition to see how many rules it 
includes, and do a kind of meta-analysis of the patterns. }


...<snip>

RJF


  • Prev by Date: Re: Problem in plotting Bifurcation Diagram (ListPlot with
  • Next by Date: Re: Re: error with Sum and Infinity
  • Previous by thread: Re: error with Sum and Infinity
  • Next by thread: Re: Re: error with Sum and Infinity