home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / programm / 3373 < prev    next >
Encoding:
Text File  |  1992-12-30  |  2.6 KB  |  76 lines
  1. Newsgroups: comp.programming
  2. Path: sparky!uunet!news.uiowa.edu!hobbes.physics.uiowa.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!phage!boutell
  3. From: boutell@isis.cshl.org (Tom Boutell)
  4. Subject: Re: Programming by Description of Output...
  5. Message-ID: <C036t1.KCH@phage.cshl.org>
  6. Sender: news@phage.cshl.org
  7. Organization: Cold Spring Harbor Labs
  8. References: <C01yxr.BGF@phage.cshl.org> <1992Dec30.174004.4168@cs.cornell.edu>
  9. Date: Wed, 30 Dec 1992 19:15:01 GMT
  10. Lines: 64
  11.  
  12. In article <1992Dec30.174004.4168@cs.cornell.edu> karr@cs.cornell.edu (David Karr) writes:
  13. >In article <C01yxr.BGF@phage.cshl.org> boutell@isis.cshl.org (Tom Boutell) writes:
  14. >>Initial state:
  15. >>Array A[] contains n whole numbers... 
  16.  
  17. >This sounds like automatic programming, which is an old idea.
  18. >Frederick P. Brooks mentioned it in an article a couple of years ago,
  19. >entitled (I think) "No Silver Bullet."
  20.  
  21. Interesting. I know a lot of discussion of the subject has been done.
  22.  
  23. >How much easier is it to specify a program by predicates on its input
  24. >and output rather than by an algorithm?  
  25.  
  26. An excellent question. I gather Prolog programmers have discovered
  27. it is often as much or more work than writing the algorithm, as
  28. you point out.
  29.  
  30. >I contend it's not as easy
  31. >as one might hope.  For example, is the following legal I/O for your
  32. >specification:
  33. >
  34. >A[] (input):   3 2 1 3 2 1 3 2 1
  35. >B[] (output):  1 2 3 3 3 3 3 3 3
  36. >
  37. >Each element of A[] appears in B[], but not with the same count of 
  38. >repetitions.  Is this what you intended?
  39.  
  40. Interesting point. An extension of the terminology is needed to
  41. express this problem succinctly, which in turn requires its own
  42. mathematical definition; and I imagine similar difficulties will
  43. appear in describing most problems.
  44.  
  45. This doesn't mean it's not worth pursuing the notion, though,
  46. so attempting to respond:
  47.  
  48. The following definitions are made:
  49.  
  50. All objects have values. Objects exist independent of their values;
  51. two distinct objects, for instance, may have the value 3.
  52.  
  53. Arrays are objects whose value is an ordered, uniquely indexed
  54. list of objects.
  55.  
  56. Now, the description of B[] is amended to read:
  57.  
  58.   One duplicate of each object in A[] appears in B[]...
  59.  
  60. These are reasonable definitions and they seem to handle the
  61. problem you pointed out. I recognize that the amount of time spent
  62. on this could have been spent, say, devising a sorting
  63. algorithm, but the idea (and it is only an idea, and may not
  64. work well in practice) is that one only has to make these
  65. definitions and get the hang of them once.
  66.  
  67. >
  68. >-- David Karr (karr@cs.cornell.edu)
  69.  
  70. -T
  71.  
  72. -- 
  73. Tom Boutell, boutell@cshl.org
  74.  
  75. Clausthaler is the best non - alcoholic beer in the known universe.
  76.