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

**References**:**Re: error with Sum and Infinity***From:*Richard Fateman <fateman@cs.berkeley.edu>

**Re: error with Sum and Infinity***From:*Richard Fateman <fateman@cs.berkeley.edu>

**Re: Problem in plotting Bifurcation Diagram (ListPlot with**

**Re: Re: error with Sum and Infinity**

**Re: error with Sum and Infinity**

**Re: Re: error with Sum and Infinity**