I appreciate the opportunity to make a few additional comments about my review.
I first learned about Macsyma (and CASs) in 1974 when I took a calculus course
from Cleve Moler (later to be the author of Matlab) at the University of New
Mexico. Cleve's demonstration of Macsyma in this class really piqued my
interest in symbolic mathematics and ultimately led to me working at the
Massachusetts Institute of Technology's Laboratory for Computer Science in the
summer of 1980 where I collaborated
with Richard Pavelle on improving Macsyma's
tensor package. Since then, I have continued to work with CASs, doing a PhD
under Stanly Steinberg at UNM on ``Symbolic Calculation and Expression Swell
Analysis of Matrix Determinants and Eigenstuff'', in which, among other things,
I looked at the eigen code of every CAS I could get my hands on. These days I
am a consultant. One of my clients has been Macsyma Inc. (whom I have not
worked with since last summer) where I was involved in improving their linear
algebra capabilities. I have * also* taught (with Stan Steinberg) two
Mathematica workshops. I have advised several of my colleagues about how to
use Maple effectively as well. In addition, I have made an effort to learn how
to use Axiom, Derive and Reduce (and recently MuPAD).

I approached this review with an applied mathematician's bias---I wanted to
produce an absolutely correct answer with a minimum of fuss and as quickly as
possible. I was less interested in the exact style needed to produce a result.
I tended to emphasize symbolic calculations since this is what originally made
CASs special in relation to numeric packages. I find that each system has its
good and its bad points; I would not recommend any single system as the one and
only choice---it depends very much on what the user plans to do and how he or
she reacts to the style inherent in each system. Every time I am asked for
advice on which system to choose, I list the various strengths and weaknesses
that I am aware of (after doing this review, quite a few!) and let them make
their own choice. I think that it is great that so many really quite good
systems are available---competition improves all our choices! I do admit that
my selection of problems has been influenced by both successes and
failures---it is useful both to see what each system can do and what each
system * cannot* do.

In order to be as fair as possible, I sent out a pointer to the review to each
of the vendors whose package I tested (or to someone associated with them who
then forwarded the message on) before I ever made it public. The version that
was published was a result of a large number of comments from many of these
people (including Mr. Issaevitch). I am now in the process of adding many
additional problems in some of the less well covered areas. In regards to
speed and memory issues, I also find this very problem dependent. However, in
the table below, I present one data point: the time and memory needed to run
the complete set of problems in the review for 4 of the 6 systems
(unfortunately, I do not have values for Derive and Reduce). All calculations
were performed on a SPARC-2 and the numbers are from the Unix csh ` time`
mechanism. I should note that a good amount of the time was spent loading
various packages and so not indicative of how fast running several calculations
of the same kind might be. Nonetheless, the results are intriguing.

Michael Wester

Sun Apr 23 10:32:10 MDT 1995