home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!stanford.edu!ames!agate!peoplesparc.Berkeley.EDU!fateman
- From: fateman@peoplesparc.Berkeley.EDU (Richard Fateman)
- Newsgroups: sci.math.symbolic
- Subject: Re: Space efficiency (Was: The Real Meaning of Efficiency?)
- Date: 20 Nov 1992 17:05:03 GMT
- Organization: University of California, Berkeley
- Lines: 30
- Message-ID: <1ej5rvINN3fq@agate.berkeley.edu>
- References: <18NOV199217533011@reg.triumf.ca> <1eghvuINNi6i@crcnis1.unl.edu> <1992Nov20.051351.18180@alchemy.chem.utoronto.ca>
- NNTP-Posting-Host: peoplesparc.berkeley.edu
-
- One of the potential advantages of using a language like Common Lisp
- is that it is possible to use tools developed outside the CAS
- community to good advantage. CL compilers have settings to "optimize"
- space, time, debuggability, and/or some combinations. It is also
- possible to use tools like "memoization" (like Maple's option
- remember, or a trick available in Mathematica [and Macsyma]) for
- remembering certain kinds of function/value pairs. This tends to
- trade lots of space for saving time, at least when it works.
-
- But these are often ineffective when the algorithm must really be
- changed by someone with a higher perspective on what is getting done.
-
- One area in which space certainly was a consideration (and which
- helped speed things up) was in the Poisson Series package in
- Macsyma. Subexpressions like 3*u+4*v+5*w-3*x+5*y+7*z are stored
- in one machine word. There are undoubtedly trade-offs in time v. space
- in systems that map from abstractions to representations in some
- controlled fashion (Axiom should do this).
-
- I think that Maple, at least in its early days, as well as Macsyma
- in its early days (on a 1.2 megabyte time-shared PDP-6) were concerned
- with "space" generally, though they may have lost sight of that.
-
- So, people have thought about space in these systems, at least in
- some respects.
-
-
- --
- Richard J. Fateman
- fateman@cs.berkeley.edu 510 642-1879
-