home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / talk / origins / 14415 < prev    next >
Encoding:
Text File  |  1992-11-18  |  3.3 KB  |  81 lines
  1. Newsgroups: talk.origins
  2. Path: sparky!uunet!destroyer!news.iastate.edu!pv7440.vincent.iastate.edu!btd
  3. From: btd@iastate.edu (Benjamin T Dehner)
  4. Subject: Re: Laying a trap
  5. Message-ID: <btd.722108058@pv7440.vincent.iastate.edu>
  6. Keywords: Computer program, random, mutation, chess
  7. Sender: news@news.iastate.edu (USENET News System)
  8. Organization: Iowa State University, Ames IA
  9. References: <1992Nov18.133247.8546@city.cs>
  10. Date: Wed, 18 Nov 1992 17:34:18 GMT
  11. Lines: 68
  12.  
  13. In <1992Nov18.133247.8546@city.cs> lionel@cs.city.ac.uk (Lionel Tun) writes:
  14.  
  15. >I would like to pose a couple of questions and gauge the
  16. >reactions of evolutionists (and creationists if any are
  17. >reading). As computer programs are flavour of the month..
  18.  
  19.     Um, first of all, the two scenarios you post below are not
  20. equivalent.  I'll get to why in a second.
  21.  
  22. >1
  23. >Lets say there is a computer program which `knows' the
  24. >legal moves of chess - lets call it ChessMover.
  25. >ChessMover plays very poor chess because its moves are
  26. >made at random. But it does play very fast. ChessMover
  27. >is small, compact and extremely efficient. But it plays
  28. >bad chess because it has not been designed with any
  29. >chess playing algorithms at all.
  30.  
  31. >Would it be possible to subject ChessMover to random
  32. >mutations, so that eventually you evolve ChessPlayer,
  33. >a chess program which plays very well, say at master
  34. >level?
  35.  
  36.     If you simply do random mutations, no.  There is no reason
  37. for it to get better.  IF, however, if you have all mutated chess programs
  38. play against each other, and kill off all of the ones that lose a lot,
  39. the 'winning' algorithm will survive to perhaps mutate into a more winning
  40. algorithm.
  41.  
  42. >2
  43. >For those of you who are not game fans, but more business
  44. >oriented:
  45. >Consider a spreadsheet program such as Lotus123 or
  46. >QuattroPro. Lets say you have a small calculator program,
  47. >like the toy ones which pop up in some windowing front
  48. >ends. Would it be possible to apply random mutations to
  49. >Calculator until it evolves into Spreadsheet?
  50.  
  51.     This is not equivalent to the above: what is the driving force
  52. behind the change?  How do you kill off 'unsuccessful' spreadsheet
  53. programs?  In the chess example, there was a simple rule: win or die.
  54. In this one, however, there is no rule of success, unless you already
  55. have some pre-existing model of a spreadsheet that you measure things
  56. to.  
  57.  
  58. >Please note, both Calculator and ChessMover are small (by
  59. >today's standard) programs, lets say about 2 to 4K for the
  60. >executable. Shreadsheet and ChessPlayer must obviously be
  61. >of a more substantial size (I can't remember how big Lotus
  62. >is). If you like, you can randomly modify the source code
  63. >and compiler, rather than the executables, if you think this
  64. >will make it less brittle. Random modification includes of
  65. >course random additions. You might prefer the source code
  66. >approach as the compiler will reject programs which will
  67. >not even compile, let alone run. If you wish to modify
  68. >the compiler, you can keep a copy of the old compiler to 
  69. >compile it with.
  70.  
  71. >--
  72. >Lionel Tun   (lionel@cs.city.ac.uk)
  73. >Vision Group, City University, London, EC1V 0HB. 071-477 8000 x 3889
  74.  
  75.  
  76. -----------------------------------------------------------------------------
  77. Benjamin T. Dehner    Dept. of Physics and Astronomy 
  78. btd@iastate.edu       Iowa State University 
  79.                       Ames, IA 50011
  80.  
  81.