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.