MathGroup Archive 1992

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

Search the Archive

important parameters not configurable

  • To: mathgroup at
  • Subject: important parameters not configurable
  • From: Scott Perkins <perkins at>
  • 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

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

  • Prev by Date: Re: efficiency of Mma list operations
  • Next by Date: Technical Writer wanted
  • Previous by thread: Re: efficiency of Mma list operations
  • Next by thread: Technical Writer wanted