home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / math / symbolic / 3047 < prev    next >
Encoding:
Text File  |  1992-11-19  |  2.4 KB  |  41 lines
  1. Newsgroups: sci.math.symbolic
  2. Path: sparky!uunet!utcsri!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!mroussel
  3. From: mroussel@alchemy.chem.utoronto.ca (Marc Roussel)
  4. Subject: Space efficiency (Was: The Real Meaning of Efficiency?)
  5. Message-ID: <1992Nov20.051351.18180@alchemy.chem.utoronto.ca>
  6. Organization: Department of Chemistry, University of Toronto
  7. References: <18NOV199217533011@reg.triumf.ca> <1eghvuINNi6i@crcnis1.unl.edu>
  8. Date: Fri, 20 Nov 1992 05:13:51 GMT
  9. Lines: 30
  10.  
  11.      Others have rightly pointed out that a concept of time efficiency that
  12. does not include the programmer's time is inadequate in a modern
  13. research environment.  Unfortunately, almost everyone seems to have
  14. ignored space efficiency in designing their symbolic algebra libraries.  I
  15. spent several frustrating hours yesterday trying to do a tricky
  16. calculation with Maple on a busy machine, all because the size of the
  17. computation kept growing beyond available resources.  (We have 128MB of
  18. memory, of which about 30MB was available during this session.  I did
  19. eventually manage to run my job by changing my approach to the problem,
  20. but the relatively trivial computation I was engaged in should have fit
  21. in 30MB.  The library routines involved were obviously written by someone from
  22. the "RAM is cheap" school of thought.)  What I and, I'm sure, many
  23. other scientists could really use is the ability to tell a symbolic
  24. algebra program whether to trade time for space or vice-versa.  Quite
  25. often, making some sort of compromise is the only way to get the
  26. calculation through the machine.  I'm perfectly willing to compromise on
  27. turn-around time if it's the difference between successfully completing
  28. a calculation and staring at yet another "Object too large" message.
  29.      I do know about FORM.  One of these days, I'll have to take a good
  30. hard look at it.  My preliminary impression (based on inspecting the
  31. manual) is that the type of computations which I most commonly carry
  32. out are not naturally expressed in FORM's language.
  33.      I would be interested to hear whether the major players (the Symbolic
  34. Computation Group, Wolfram Research, the vendors of various Macsyma variants,
  35. etc.) worry much about space efficiency when they are creating new
  36. library code.  I get the impression that the answer is no, at least for
  37. Maple and Mathematica.
  38.  
  39.                 Marc R. Roussel
  40.                                 mroussel@alchemy.chem.utoronto.ca
  41.