important parameters not configurable

*To*: mathgroup at yoda.physics.unc.edu*Subject*: important parameters not configurable*From*: Scott Perkins <perkins at acs00.cc.vanderbilt.edu>*Date*: Mon, 4 May 92 12:49:28 CDT

It is quite clear to me that the bugs with Mathematica are, in fact, bugs in Mathematica. I know this for four reasons: 1. We have been using Mathematica since version 1.1 on Systems 6.03, 6.04, 6.05, 6.07, 7.0, and 7.01 (Tune-Up 1.0 included.) Mathematica has always been prone to crash, especially when doing recursive math of any kind. On system 6, Mathematica 2.0 crashed much more frequently than version 1.2 did. 2. We have seen a common theme to the error messages; most of them are related to memory, and the most common error is stack overflow. Any good C or Pascal or FORTRAN prgrammer can relate to the difficulties of using a finite amount of stack memory to do recursion. This is a problem on all types of computers. Wolfram Research is going to have to spend more time fine-tuning their range-checking in each routine, and spend less time adding annoying features such as network copy need for copy-protection. As it is, no one would want to steal it anyway. There is no sense in adding cool new features like sound and background tasking when the math routines (the most important features) are still not perfected. Wolfram could have solved these bugs by now if they were focused on the task of debugging. 3. I use many other programs to do many other activities including networking of all sorts, word processing, spreadsheets, graphics, playing movies and so on. If I can go for weeks without restarting my Macintosh (I can), then there is nothing wrong with System 7 or the other programs I am using. To be fair, none of the other programs do recursion. But the fact remains that Mathematica should not crash under any circumstances no matter what is typed in a notebook, and no matter has little memory is allocated to the program. If there is not enough memory Mathematica should just say so and refuse to perform the operation. 4.Even on a protected memory OS such as Unix, Mathematica will still crash when it runs out of memory, and while it doesn't usually take down the whole system, it still crashes and takes your notebook with it. Most Unix systems are configured with large amounts of virtual memory and stack memory. This helps to mask the bugs since it will take more recursions to cause a crash, but the bugs are still there. By the way, the only other program I have used that does recursive symbolic math is Maple V, and it also crashes occasionally. There won't be any quick fixes for Mathematica that suddenly make the package perfect. The only way WRI can fix Mathematica is with hard work and determination, supported by a steady stream of detailed bug reports that include example code. I would also like to point out a very important fact. Those of you who have programmed the Macintosh using C or Pascal or FORTRAN probably already know this. The programmers at Wolfram have control over the stack size that is allocated to Mathematica when the program is launched. The end user does not have control over this very important configurable parameter. Stack size is so important because a routine that crashes on a small stack might actually work on a larger stack. No matter how much memory you allocate to Mathematica (even 80MB or more,) Mathematica will decide for itself how much of it to use for the stack. Giving Mathematica more memory will allow you to have larger notebooks, but it is not the answer to these bugs. Infinite recursion cannot be done on a finite stack, so range-chacking is the only solution. Only Wolfram Research is in a position to fix the range checking. Scott Perkins Vanderbilt University Computer Center