home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / sci / math / symbolic / 3335 < prev    next >
Encoding:
Internet Message Format  |  1992-12-25  |  2.3 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!peoplesparc.Berkeley.EDU!fateman
  2. From: fateman@peoplesparc.Berkeley.EDU (Richard Fateman)
  3. Newsgroups: sci.math.symbolic
  4. Subject: Computer Algebra languages slow (was:Re: "shut up and deal the cards")
  5. Date: 25 Dec 1992 19:52:35 GMT
  6. Organization: University of California, Berkeley
  7. Lines: 45
  8. Message-ID: <1hfoq3INN68i@agate.berkeley.edu>
  9. References: <Bzs70r.B1B@news.cso.uiuc.edu> <1992Dec25.001234.21234@u.washington.edu>
  10. NNTP-Posting-Host: peoplesparc.berkeley.edu
  11.  
  12. In article <1992Dec25.001234.21234@u.washington.edu> petry@zermelo.math.washington.edu (David Petry) writes:
  13. >I gather
  14. >that good Mathematica programmers must learn a bunch of slick tricks to
  15. >write reasonably efficient programs.  That bothers me.
  16. >
  17. >Does anyone have any comments?
  18.  
  19. In a type-less language, a construction such as x:=x+1  (or x++) has to be
  20. fairly general.  For example, x may be a symbolic expression, and adding
  21. 1 to it may be fairly expensive.
  22. Other expensive operations include comparison, arbitrary-precision 
  23. integer or floating-point arithmetic, etc.  Even when these features are
  24. not used, the interpreter has to be prepared to check this possibility.
  25. (Some interpreters are, nevertheless, faster than others (e.g. compare
  26. Maple to Mathematica -- Maple is, I suspect, much faster.  It also has
  27. a much simpler evaluation mechanism.)
  28.  
  29. In any interpreter-language, there is an inherent disadvantage to programming
  30. "in the small".  Some of this disadvantage can be overcome by using types
  31. (at least sometimes) as is possible in Lisp, and compiling.
  32.  
  33. Some well-known languages, by making type
  34. declarations required all the time, inhibit some kinds of expressiveness
  35. (there may be arguments on this point), but that's my current opinion.
  36.  
  37. Another way around this is to promote (as in Mathematica), high-level
  38. transactions that do type-checking once, and then use those types for
  39. the remainder of the operation.  For example, creating a Table with
  40. the index computation type-checked but once.  If there is a bad fit
  41. between the provided high-level commands and the needs of the algorithm,
  42. that's too bad.
  43.  
  44. Finding the good fit, if there is one, is what Mr. Petry calls a trick,
  45. and it is inherent in Mathematica's approach to efficiency in the
  46. user language.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. -- 
  55. Richard J. Fateman
  56. fateman@cs.berkeley.edu   510 642-1879
  57.