Subject: Sun-Symbolic-Math Digest v1n5 Sun-Symbolic-Math Digest Tuesday, March 29, 1988 Volume 1: Number 5 Editor: Steve Christensen, steve@spock.ncsa.uiuc.edu, (217)244-0544 Today's Topics: Administrative Stuff Overview of Symbol Manipulation Re: Benchmarks and Gentran Complete list of updates of the new version of Maple (4.2) Announcement of Maple 4.0 for the Cray 2 Send contributions to: Sun-Symbolic-Math@spock.ncsa.uiuc.edu Send subscription add/delete requests to: Sun-Symbolic-Math-Request @spock.ncsa.uiuc.edu For BITNET: Sun-Symbolic-Math%spock.ncsa.uiuc.edu@uiucvmd.bitnet Sun-Symbolic-Math-Request%spock.ncsa.uiuc.edu@uiucvmd.bitnet Anonymous ftp to archive: ftp.ncsa.uiuc.edu cd to Directory /usr6/ftp/Symbolic -------------------------------------------------------------------------- Subject: Administrative Stuff There has been a request to give subscribers the option of a shorter mailing name. So, shortly SSM-request@spock.ncsa.uiuc.edu and SSM@spock.ncsa.uiuc.edu can be used in place of Sun-Symbolic-Math-Request @spock.ncsa.uiuc.edu and Sun-Symbolic-Math@spock.ncsa.uiuc.edu respectively. If you have not received previous mailings, email the request address above with the numbers not received. ------------------------------------------------------------------------- Date: Thu, 24 Mar 88 09:49:50 PST From: Larry Seward Subject: Overview of Symbol Manipulation Here is a summary of sym alg systems, submitted some months ago to sci.math.symbolic (the USENET newsgroup for symbolic algebra). For more info on sci.math.symbolic or access to archives please contact Lawrence Leff: smu!leff@uunet.UU.NET E1AR0002@SMUVM1.bitnet ...!decvax!allegra!convex!smu!leff Larry Seward Date: 15 Aug 87 22:50:04 GMT From: stanly@crunch.unm.edu (Stanly Steinberg) Subject: Overview of Symbol Manipulation Organization: Math Department, University of New Mexico OVERVIEW OF SYMBOL MANIPULATION Stanly Steinberg Department of Mathematics and Statistics University of New Mexico Albuquerque, New Mexico 87131 505-277-4733 January, 1987 No doubt the idea of using a computer to manipulate symbols has been around as long as the idea of using computers to manipulate numbers. Currently there are many areas in which computers are used to manipulate symbols rather than numbers; for example, text processing, artificial intelligence and symbolic mathematics. The interest here is in programs that do symbolic mathematics; that is, programs that do many of the nonnumeric calculations from high school algebra, university calculus, ordinary differential equations and many other calculations usually thought of as being within the exclusive domain of humans. The programs that perform such calculations are frequently called symbol manipulators. Symbol manipulators were certainly capable of doing interesting problems in the early 1960's. Even though symbol manipulators are used extensively, they have not gained general acceptance by the computing public. It appears that improvements in software and hardware will encourage more extensive use of the symbol manipulation technology. For a far more detailed discussion of symbol manipulation and symbol manipulators see the text by Buchberger (the references are listed below). Symbol manipulation programs can be conveniently divided into two categories, special purpose and general purpose. The interest here is in general purpose symbol manipulators, but it is important to realize that special purpose symbol manipulators have played a crucial role in certain scientific areas. An idea of the importance of such programs can be obtained by looking at the article by Broucke which describes the use of symbol manipulators in celestial mechanics. General purpose symbol manipulation programs have made significant contributions to a wide range of problems as a brief look at the conference proceedings listed below will show. The articles by Elvey, Ogilvie, Pavelle, et. al., Steinberg, and Stoutemyer provide a more detailed overview of general purpose symbol manipulators than will be given here. Some of the general purpose symbol manipulators are MACSYMA, Maple, MuMath, REDUCE and SMP (addresses are given below). The program REDUCE has been available to the public for many years and MuMath has been available for several years. Unfortunately MACSYMA and SMP were not available to the general public until the fall of 1983, apparently due to organizational and legal problems. Maple was released in 1984. Until recently MACSYMA, the most powerful of the symbol manipulators, was available on computers at MIT to which many users around the country had access using the ARPAnet. This program has been modified to run on VAX computers; that version of the program was called VAXIMA. MACSYMA is being sold (at modest cost to universities) by Symbolics. The descriptions of SMP indicate that it will have substantially more facilities than any other symbol manipulator except possibly MACSYMA. However, some experience with the program is required before any judgments can be made. There are probably more users of REDUCE than all of other symbol manipulation programs. The facilities in REDUCE are modest when compared with those of MACSYMA and SMP. One the other hand, the program is well documented, easy to use, and powerful, so if a problem falls within its domain, it is perhaps the best program to use. A well documented user library would make this program much more useful. The Maple program appears to be of about the same size as REDUCE. The MuMath program is designed to run on small micro-computers and seems not to be powerful enough to do any large scientific computing. This program could be used in high school and college to interest students and faculty in symbol manipulation. High school students are probably prepared to do nontrivial symbolic problems before they can do nontrivial numerical problems. In early 1987, Hewlett-Packard introduce a hand-held calculator (model 28C for approximately two hundred dollars) that is capable of doing nontrivial symbolic calculations. It is a common experience for a person who is first using a symbol manipulator to feel that the program is incredibly powerful. In fact these programs are very powerful but they also have their limitations. Symbol manipulation programs are capable of doing infinite precision rational arithmetic, algebraic simplification, expanding and factoring, finding greatest common denominators and other operations of the type found in high school algebra courses. The programs are also programming languages and this adds much to their power. Some of the programs are capable of handling expressions that contain millions of characters and perform, in seconds, calculations that would require humans many tedious hours. The programs also know how to differentiate and integrate. Although it is not well known, there are algorithms for integrating certain large classes of functions. When an integration problem falls in one of the known classes, the programs are capable of doing integrations where the answer may fill several printed pages and appear impossible to do by hand. It is experience with these types of problems that leads to optimism about symbol manipulation. It is also not difficult to find examples that humans can do easily and the programs are incapable of doing. As users of symbol manipulation programs become more experienced they soon discover there are many limitations to the symbol manipulation program they are using. The programs may run out of memory, may take too much time, may not contain a needed algorithm or may be set up in such a way as to make some problems unreasonably difficult to solve. Not unlike the notion of stability in numerical calculations, the concept of intermediate expression swell plays an important role in symbolic calculations. Intermediate expression swell refers to a situation where the statement and results of some calculation are rather small but some intermediate steps in the calculation produce very large expressions. Intermediate expression swell can be reduced by careful analysis and programming of problems (see Steinberg and Roache), but some form of the difficulty is inherent in many interesting problems. Consequently many problems require large amounts of memory and time to be completed. Perhaps the most important problem with symbol manipulation programs is the limited amount of mathematics that they know (see Steinberg). With certain noteworthy exceptions, the programs know relatively little about junior and senior college level applied mathematics. The MACSYMA packages for solving ordinary differential equations and tensor manipulations are two of the exceptions as is some of the material listed in the SMP manual. Although there are many symbol manipulation users who are creating programs using advanced level mathematics, there is too little effort being expended on incorporating this mathematics into the main body of the programs. There are libraries of user-contributed programs but this seems to be a rather ineffective way of making a wide range of facilities available to the user community. Some workers have made some inroads into this problem in certain mathematical areas: for instance, see the thesis of M. Wirth. An example of mathematics being set up in a symbol manipulation program in a way that limits the usefulness of the program is given by the dependencies idea used in the MACSYMA differentiation programs. This idea works well in simple problems but causes considerable grief for problems involving complicated coordinate changes (see Wester and Steinberg). These problems and many others are now under serious attack by the symbol manipulation community as a brief perusal of the conference proceedings listed below shows. The most promising news for the symbol manipulation community is that a group, under the direction of Prof. R. Fateman, in the EECS department at the University of California at Berkeley is creating a new symbol manipulation system (see the articles by Fateman and Williamson). The system will no longer be based on LISP or other standard languages but instead will be based on a new language that will attempt to merge the underlying mathematics and mathematical objects with the algorithms and data types and the hardware to provide a substantial gain in speed and reduce memory requirements over the existing systems. Because much care is being exercised to embody good mathematics in the underlying language, there seems little doubt that many problems that are now tedious or impossible to do with the current systems will be able to be done nicely with the new system. Considerable effort is being directed toward developing user interfaces that are appropriate for both the experienced user and the novice user. Another component of the project will bring together experienced users of symbol manipulation systems who have a strong applied mathematics background in order to incorporate higher levels of mathematics in the the new system. A similar effort is being made by IBM (see Jenks); they have a new manipulator called Scratchpad available. Symbol manipulation programs are large and need to be able to handle large expressions. As the size of the expressions grows so does the use of computer time; it is not uncommon to hear experienced users talk about problems that run many hours on a large computer. Thus symbol manipulators place a considerable strain on the computing resources. Because of this demand on computing resources, many symbol manipulators used to run in batch mode or on special machines as MACSYMA did at MIT. Batch mode symbolic computing turns out to be unsatisfactory because of another problem inherent in symbolic computing; the powerful symbol manipulation programs are not predictable enough to be easily programmed without first testing various ideas interactively. All of the symbol manipulation programs mentioned above are now interactive. An important hardware development for the symbol manipulation community was the appearance of the VAX computer. The ability of these machines to automatically page information on the disk to the main memory allows the machine to easily run large interactive jobs. Maple, REDUCE, SMP and MACSYMA now all run on these machines. If a VAX computer has 3 or more megabytes of main memory and is lightly loaded, then MACSYMA will run very nicely. However, if the machine is heavily loaded or has a small main memory, then the performance of MACSYMA and the machine is seriously degraded. Consequently, users of symbol manipulation programs are frequently required to run in low priority or late at night. Another hardware related problem with the current symbol manipulators is their input and output. The input is typed in a linear FORTRAN like format. Programs that can understand written formulas are feasible but expensive and inconvenient. However, once some information is typed into a symbol manipulator and displayed on a graphics screen, then a ``mouse'' or light pen can be used to manipulate the information or direct the program to manipulate the information. The output of current programs is usually a relatively klutzy two dimensional format. However, some programs are capable of producing text-book quality output by using a laser printer, and similar results can be obtained by using a high resolution graphics screen. Since human vision plays an important role in understanding formulas, high quality output will greatly enhance the usefulness of symbol manipulation programs. Such technology will allow symbol manipulators to mimic pencil and paper calculations which will make the use of the programs more intuitive. The system being developed by the Fateman group will take advantage of graphics screens and the ``mouse'' technology. Some prototype systems were discussed at the Waterloo conference. An optimal environment for symbol manipulation work is the new workstations. A machine with 4 megabytes of main memory, large hard disk drive, 16 megabytes of virtual address space, high resolution graphics screen, and a ``mouse'' are now available and provide better service for a single user than a time shared VAX. A network of such machines with a common disk drive would be ideal for a community of users. All of the symbol manipulators mentioned above now run on workstations. Symbolics has MACSYMA running on their LISP machine; a LISP machine is a large workstation and seems ideal for doing symbolic calculations. The currently available software and hardware has made symbol manipulation a more fruitful and productive activity than just a few years ago. The combination of the new inexpensive hardware and software will certainly cause a substantial growth in the user community. JOURNALS SIGSAM Bulletin, Special Interest Group on Symbolic & Algebraic Manipulation of the ACM (Association for Computing Machinery). 11 West 42nd Street, New York, NY 10036. Journal of Symbolic Computation, B. Buchberger, Editor, Johannes Kepler University, A4040 Linz, Austria. PAPERS R.A. Broucke, A Fortran-4 system for the manipulation of symbolic Poisson series with applications to celestial mechanics, Preprint, Institute for Advanced Study in Orbital Mechanics, University of Texas at Austin, 1981. R.D. Drinkard, Jr. N.K. Sulinski, MACSYMA: A program for computer algebraic manipulation (demonstrations and analysis). New London Laboratory, Naval Underwater Systems Center, New London, Connecticut 06320. J.S.N. Elvey, Symbolic Computation and Constructive Mathematics, Research Report, Dept. of Computer Science, Univ. of Waterloo, Waterloo, Ontario, Canada, 1983. R.J. Fateman, My view of the future of symbolic and algebraic computation, SIGSAM Bulletin, 18, 1984, 10-11. M.A. Hussain, B. Noble, Applications of MACSYMA to calculations in applied mathematics. General Electric Co. R.D. Jenks, 11 keys to new scratchpad, Proceeding of EUROSAM 84, Edited by J. Fitch, Springer-Verlag, New York, 1984. J.F. Ogilvie, Applications of computer algebra in physical chemistry, Computers and Chemistry, 6, 1982, 169-172. R. Pavelle, M. Rothstein, J. Fitch, Computer algebra, Scientific American, Dec. 1981. S. Steinberg, Mathematics and symbol manipulation, ACM SIGSAM Bulletin, 16, 1982, 11-15. S. Steinberg, P. Roach, Symbolic manipulation and computational fluid dynamics, Journal of Computational Physics, 57(1985), pages 251-284. D.R. Stoutemyer, Symbolic computation comes of age, SIAM News, 12, 1979. M. Wester, S. Steinberg An extension to MACSYMA's concept of functional differentiation, SIGSAM Bulletin, 17, 1983, 25-30 A survey of symbolic differentiation implementations, 1984 MACSYMA User's conference. C. Williamson, Jr., Taylor Series solutions of explicit ODE's in a strongly typed algebra system, SIGSAM Bulletin, 18(69), 1984, 25-29. M.C. Wirth, On the automation of computational physics, Lawrence Livermore Laboratory, 1980. TEXTS B. Buchberger, G.E. Collins, R. Loos, R. Albrecht (Editors) Computer Algebra, Symbolic and Algebraic Computation, Springer-Verlag, New York, 1982. R.E. Zippel, Algebraic Manipulation (Course Notes) Dept. of Computer Science, MIT, 1982. K.O. Geddes, Algebraic Algorithms for Symbolic Computation (Course Notes) Dept. of Computer Science, University of Waterloo. R.H. Rand, Computer Algebra in Applied Mathematics: An introduction to MACSYMA, Pittman, Marshfield, 1984. CONFERENCES AND PROCEEDINGS R. Fateman (Chairman), Proceedings of the 1977 MACSYMA User's Conference, NASA, Berkeley, 1977. E. Lewis (Editor), Proceedings of the 1979 MACSYMA User's Conference, Washington, D.C., 1979. P.S. Wang (Editor), SYMSAC '81, Proceedings of the 1981 ACM Symposium on Symbolic and Algebraic Computation, Utah, 1981, Published by ACM. J. Calmet (Editor), EUROCAM 82, European Computer Algebra Conference, Marseille, France, April, 1982, Lecture Notes in Computer Science, 144, Springer-Verlag, New York, 1982. See SIGSAM Bulletin, 16-1, Jan. 1982, for a program of the meeting. M. Mignotte (Chairman), EUROCAL '83, European Computer Algebra Conference, London, March 1983, To be published. J. Fitch (Editor), EUROSAM 84, International Symposium on Symbolic and Algebraic Computation, Cambridge, England, July 1984, Lecture Notes in Computer Science, 174, Springer-Verlag, New York, 1984. V. E. Golden (Editor), Proceedings of the 1984 MACSYMA User's Conference, Schenectady, New York, July, 1984. For copies send $30.00 to M. McGinn, General Electric Co,. Corporate Research and Development Center, P.O. Box 8, Bldg. K-1, Room 3A15, Schenectady, NY, 12301. B. Buchberger (Editor), EUROCAL '85, Linz, Austria, April, 1985. Bruce Char (Editor), SYMSAC `86, Proceedings of the 1986 Symposium on Symbolic and Algebraic Computing, ACM, 1986. W. Lassner (Chairman), EUROCAL `87, Leipzig, GDR, June 1987. A. Miola, (Chairman), FIJC-88, Roma, Italy. SYMBOL MANIPULATION PROGRAMS MACSYMA Computer Aided Mathematics Group, Symbolics Inc., 11 Cambridge Center, Cambridge, MA 02142. DOE MACSYMA Jan Mockler, National Energy Software Center, Argonne National Laboratory, 9700 S. Cass. Ave., Chicago, Illinois 60439. Leo Harten, Paradigm Associates, Inc., 29 Putnam Avenue, Suite 6, Cambridge, MA 021329. Maple WATCOM Products Inc., 415 Phillip St., Waterloo, Ontario, Canada N2L 3X2. MuMath The Soft Warehouse, 3615 Harding Ave., Suite 505, Honolulu, Hawaii 96816. REDUCE A.C. Hearn, The Rand Corporation, 1700 Main St., P.O. Box 2138, Santa Monica, CA 90406 SMP Inference Corporation, Computer Mathematics Group, Suite 501, 5300 West Century Blvd., Los Angles, CA 90045 Scratchpad Richard Jenks, Computer Algebra Group, IBM T.J. Watson Research Center, P.O. Box 218, Yorktown Heights, NY 10598. Professor Stanly Steinberg Department of Mathematics and Statistics University of New Mexico Albuquerque, NM 87121 505 277 4733 stanly@crunch.unm.edu hi!crunch!stanly@hc.dspo.gov -------------------------------------------------------------------------- Date: Mon, 28 Mar 88 09:43 EST From: Richard Petti Subject: Re: Benchmarks and Gentran I would like to make brief comments on two items in your recent mailing. 1) Your request for benchmarks: Speed of a symbolic algebra system often varies inversely with intelligence and generality. Much of our development work on MACSYMA involves increasing its intelligence or generality, and we sometimes accept modest decreases in speed to accomplish this. We believe that this is the right thing to do, especially since the cost per mip for computer power is declining so rapidly. To interpret benchmarks meaningfully, it is also necessary to cover a wide range of problems. For us, many speed-ups of less important algorithms are of lower priority than adding important new functionality. I am writing this note now - before benchmarks have been introduced in your mailing list - because I have seen some poor use of benchmarks in other software markets. They make more sense for comparing hardware running similar software than for software, unless they are quite comprehensive. 2) Regarding David Hobill's note about Gentran, Gentran will be available in the new VAX VMS MACSYMA in about a month or two, and should be available in all our new releases henceforth. Dick Petti Symbolics, Inc. Eleven Cambridge Center Cambridge, MA 02142 (617) 621-7776 petti@symbolics.com --------------------------------------------------------------------------- Date: Tue, 29 Mar 88 09:05:39 EST From: "Gaston H. Gonnet" Subject: Complete list of updates of the new version of Maple (4.2) New features that have been added to Maple for version 4.2 *** ******** **** **** **** ***** ** ***** *** ******* *** Extended syntax of the repetition statement In addition to the previous form of the repetition state- ment (for-from-by-to-while), a new form (for-in-while) has been added. Specifically, the syntax of the new form is: for in while do od where any of `for ', `in ', or `while ' may be omitted. The successive values of the loop index (i.e., the specified in the for-part of the statement) are the suc- cessive operands of . The value of the index may be tested in the while-part of the statement and, of course, the value of the index is available when executing the . As in the other form of the repetition statement, if the `while ' part is present then the test for termination is checked at the beginning of each iteration. Notation for inert functions In general, the convention to represent the inert form of a function is to capitalize the first letter of the function name. The following inert functions are known to the pretty- printer: Int, Sum, and Product. More generally, inert func- tions are used when it is desired to control the domain of com- putation (see next item). Specifying the domain of computation The general mechanism to cause a computation to be per- formed with respect to a specific coefficient domain is as fol- lows. The function to be computed is specified in its inert form (by capitalizing the first letter) and then the appropri- ate evaluator is applied to the function. At present, this mechanism is operational for two coefficient domains: (i) integers modulo m, via the mod operator; (ii) rational expressions extended by algebraic numbers (speci- fied using the RootOf notation), via the evala function. The following inert functions are known to the mod operator and to the evala function: Content Divide Factor Gcd Gcdex Interp Prem Primpart Quo Rem Resultant RootOf Sprem Extended prettyprint facility The prettyprint facility now knows about special symbols for int, sum, and product (also Int, Sum, and Product, their inert counterparts), and diff. Furthermore, it now correctly prints expressions involving the following operators: &-opera- tors (neutral operators), $, mod, union, intersect, minus, and angle-bracket operators. New Packages Several new packages of library functions have been added; the complete list of packages in this version of Maple is: difforms: differential forms package grobner: Grobner basis package group: permutation and finitely-presented group package linalg: linear algebra package np: Newman-Penrose formalism package numtheory: number theory package orthopoly: orthogonal polynomial package powseries: formal power series package simplex: linear optimization package stats: statistics package student: student calculus package Improved automatic simplifications The automatic simplification of trigonometric functions with respect to inverse trigonometric functions has been added. Improved limit and integration facilities Much of the limit function has been rewritten to improve its mathematical power, as well as its efficiency. The int facility for indefinite integration has been sig- nificantly enhanced by the installation of a complete Risch decision procedure for transcendental elementary functions. The numerical integration facility (`evalf/int`) has been improved to handle a much wider class of integrands, particu- larly integrands involving singularities and infinite limits of integration. Efficiency improvements The overall efficiency of Maple has increased about 10%. This has been achieved by moving a few routines to the compiled kernel as well as by improved algorithms in the external library. New functions (use "help(f);" in a Maple session for information about f): primpart: primpart(a,x) = a / content(a,x). eqn and latex: eqn (rewritten) and latex (new) produce typesetter output from mathematical expressions. singular: Find all singularities of an expression. RootOf: The RootOf procedure does basic simplifications. The RootOf function notation is generally a placeholder for representing roots of equations. S, C: New math fcns, the Fresnel integrals S(x) and C(x). These functions are known to various routines, including evalf, diff, taylor, and int. bspline: The function bspline(d,v,k) computes the B-spline of degree "d" as a list of segment polynomials in "v" defined on the knots "k" where "k" is a list of d+2 numbers or symbols (multiplicities allowed). zip: The function zip(f,u,v) zips u and v (two lists or vectors) into a new list or vector by application of the binary function f to each pair of elements u[i], v[i]. evala: The evala function is used for evaluation in the domain of rational expressions extended by algebraic numbers (using the RootOf notation). match: for pattern matching. student[combine] - This routine is used to rewrite unevaluated Sums and Integrals as one Sum or Integral. student[Eval] - This routine is used to cause unevaluated Sums, Limits, and Integrals to evaluate. student[makeproc] - This is an alternative name for the Maple function unapply(). student[changevar] - This function now handles infinite bounds correctly. convert routine in student package: convert(...,nested) rewrites an expression involving functional composition as nested function application; convert(...,`@`) rewrites nested function applications using composition of func- tions. Modified functions (use "help(f);" in a Maple session for more information): mod: The functions `mod`, modp, and mods have been extended to work on lists, sets, and equations. ConvexHull: deleted; now use simplex[convexhull]. testeq now successfully works for: (a) square roots when not mixed with trigonometric functions; (b) nested algebraic numbers and functions; (c) floating-point numbers. resultant(p,q,x): now allows p and q to be non-polynomial in variables other than x. gcdex(p,q,x,'s','t'): now allows p and q to be non- polynomial in variables other than x. diophant(p,q,r,x,'s','t'): now deleted; see gcdex for this functionality. numtheory[jacobi]: improved from cubic time / quadratic space to quadratic time / linear space. asympt: asympt( sum(..), ..) now uses Euler-Maclaurin expansions when appropriate. plot: now accepts an ln03 laser printer as a plotdevice and vt100 using the dec-graphics character set. Plot can also produce postcript-compatible output. indets: indets(expr,typename) returns all of the subex- pressions in expr which are of type "typename". minimize: extended and improved functionality. type: type(a, type_set); where type_set is a set of type names, will return true if a is any one of the types con- tained in the set. type/algnum: test for an algebraic number. type/polynom: The code has a user interface allowing for user-defined coefficient domains. For example: type(a, polynom, v, d); tests whether "a" is a polynomial in the variable(s) "v" with coefficients of type "d". type/ratpoly: The code has the same extension as type/polynom. For example: type(a, ratpoly, [x,y], algnum) tests whether "a" is a rational function in the indeter- minates "x" and "y" with coefficients which are algebraic numbers. type/point: A point is formally defined to be a set of equations with variables as left-hand-sides (identical to the explicit output format of the solve function). Many functions will now take points as arguments -- for exam- ple, limit now accepts points as well as single equations, as in: limit( 1/(x+a), {x=0,a=0} ) . int/def: all of the non-parametric definite integrals of the CRC tables have been included in the definite integra- tion tables (when they are not otherwise computed by the integration algorithm). trace: The trace facility has been improved so that not only entry and exit points are displayed, but also state- ments executed within the procedure (but not in sub- procedures) are displayed. Also, option "trace" may be specified for a procedure (this is the mechanism used by the trace function). sum: a new algorithm has been implemented for the summa- tion of trigonometrics and exponentials. Also, there is a user interface such that if `sum/` is defined as a procedure then it will be invoked by sum when the arbi- trary function is encountered in an expression. taylor: When floats are present, all coefficients are now evaluated by evalf. iroots: removed; it is now part of isolve. mod functions: The mod functions (names beginning with m) have been deleted; now use inert (capitalized) function names and the mod operator. I.e. mfactor --> Factor(..) mod p mgcd --> Gcd(..) mod p mgcdex --> Gcdex(..) mod p minterp --> Interp(..) mod p mquo --> Quo(..) mod p mrem --> Rem(..) mod p mres --> Resultant(..) mod p solve: improvements include solving inequalities, solving equations containing RootOfs, and solving equations with radicals in a general form. solve: solve( identity( , x ), ) solves identities in a single, given variable. This is equivalent to a powerful pattern matching in one main variable. msolve: special code is now used for solving large sys- tems of equations mod 2. =============================================== Would you prefer the troff input for this file? Thanks, Gaston Gonnet. . ------------------------------------------------------------------------- Date: Tue, 29 Mar 88 09:21:51 EST From: "Gaston H. Gonnet" Subject: Announcement of Maple 4.0 for the Cray 2 I think that this will be of great interest to the scientific-computation community: Announcement of Maple 4.0 for the Cray 2. Michael Monagan Maple 4.0 is now available for the Cray 2 under the UNICOS (Unix system V) operating system. The port was done in January 1987 on one of the Minnesota Super Computer center's Cray 2 systems, under the support of Dr. Tom Walsh (University of Minnesota), and with the help of Stuart Levy and Barry Rackner (Minnesota Super Computer Center). Working from Waterloo, the port took three weeks of part time work. This is some evidence of Maple having attained a relatively high degree of portability, portability being one of the major design issues. Timing tests indicate that Maple on a Cray 2 performs approxi- mately 8.5 faster than a Vax 11/780. This rather disappointing result is, I believe, largely due to the UNICOS C compiler, which is at an early stage of development. Currently, no optimizations are done. There is a growing interest in having Computer Algebra systems available on Super Computers. The Cray 2 achieves most of its speed in being a pipelined architecture. This means that it achieves its greatest speeds on sequences of calculations which do not involve branches or subroutine calls. Such calculations are most typically encountered when processing vectors. It is widely believed, however, that the computations done in Computer Algebra systems are inherently unsuited to this "vector" process- ing. Data structures in Computer Algebra systems are highly recursive and hence, the algorithms that traverse them are recur- sive in nature. Garbage collection is such an example. One important exception to this is multi-precision integer arithmetic which could benefit from "vector" processing. Interest in Maple on the Cray 2 arose partly because Maple is written in the C programming language. The other computer alge- bra systems under consideration were Reduce and Macsyma which are written in Lisp. It is believed that typical programs written in C will "vectorize" much more so than those written in Lisp thus giving Maple an inherent advantage. Maple's data structures are all represented as dynamic vectors where operations on these vec- tors are simple iterations over them. This is the kind of compu- tation which can be vectorized automatically by a compiler. Although the present C compiler does not do any optimization, a new vectorizing compiler is being developed. It is hoped that this new compiler will result in a marked improvement in perfor- mance across a wide range of computations. To obtain copies of Maple for the Cray 2, please contact: Symbolic Computation Group, University of Waterloo, Waterloo, Ontario, N2L-3G1, Canada (519) 885-1211 ext. 3055 ------------------------------------------------------------------------ *** End of v1n5 ***