home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10647 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.4 KB
  1. Xref: sparky comp.arch:10647 comp.lang.misc:3607
  2. Newsgroups: comp.arch,comp.lang.misc
  3. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  4. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  5. Subject: Re: Hardware Support for Numeric Algorithms
  6. Message-ID: <BxLupy.M9K@mentor.cc.purdue.edu>
  7. Sender: news@mentor.cc.purdue.edu (USENET News)
  8. Organization: Purdue University Statistics Department
  9. References: <1992Nov11.100555.4706@smds.com> <721539025@sheol.UUCP>
  10. Date: Thu, 12 Nov 1992 13:27:33 GMT
  11. Lines: 37
  12.  
  13. In article <721539025@sheol.UUCP> throopw@sheol.UUCP (Wayne Throop) writes:
  14. >: From: rh@smds.com (Richard Harter)
  15. >: Message-ID: <1992Nov11.100555.4706@smds.com>
  16. >: What Bob is telling you is that there are problems
  17. >: which are so computationally demanding that computational efficiency is
  18. >: far more important than standard programming style guides. 
  19.  
  20.             ...................
  21.  
  22. >: There is a price for programming for clean code;
  23. >: in most cases the benefits far outweigh the price; sometimes they don't.
  24.  
  25. There is a price for programming in what the languagists think is clean code.
  26. Nobody except a computer programmer can read it at all!  Now I received some
  27. email from someone about the algorithm I posted in which he asked for another
  28. copy of the code where the control-path was "clear" and not defined by breaks
  29. or gotos.  Now I do not know how to do that, but analyzing breaks is not that
  30. simple for a human, either.  
  31.  
  32. >True, but I'm more sympathetic with the Jon Bentley school of
  33. >optimization, where you transform clean, correct code into arcane,
  34. >incomprehensible code by known-safe transforms, and RECORD THE
  35. >TRANSFORMS.  For example, the chapter on code tuning in Programming
  36. >Perls, especially the case study of the binary search.  Or, if I'm
  37. >remembering rightly, Bentley's book Writing Efficient Programs.  Of
  38. >course, the shortcoming in this context is that the central focus isn't
  39. >really numerical problems, but I regard that as relatively minor. 
  40.  
  41. We still have the problem of what is comprehensible to whom.  And what 
  42. is one supposed to do if the hardware operations wanted are not even
  43. expressible in the language?  Sure, one can simulate them, but nobody
  44. will be able to read THAT code.
  45. -- 
  46. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  47. Phone: (317)494-6054
  48. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  49. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  50.