home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / sci / nanotech / 527 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.6 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!rutgers!igor.rutgers.edu!planchet.rutgers.edu!nanotech
  2. From: srs@oasis.icl.co.uk (Steve Strong)
  3. Newsgroups: sci.nanotech
  4. Subject: Re: Evolution and nanotech
  5. Message-ID: <Aug.29.01.54.01.1992.13244@planchet.rutgers.edu>
  6. Date: 29 Aug 92 05:54:02 GMT
  7. Sender: nanotech@planchet.rutgers.edu
  8. Organization: ICL, Bracknell, Berkshire, RG12 4SN, UK
  9. Lines: 59
  10. Approved: nanotech@aramis.rutgers.edu
  11.  
  12.  
  13.  
  14. Ian (ian@inf.ethz.ch) wrote:
  15. : 
  16. : I contest that !  Certainly the production of function is a chancy
  17. : business but the loss of function . . . imagine the mutation
  18. : 
  19. :     ADD H010102,H100023 -> RTS
  20. : 
  21. : Where RTS is Return from Subroutine (you knew that).  This instantly
  22. : removes the entire second half of the routine, for example, removing
  23. : half the proof-reading from the program.
  24.  
  25. I feel that it would be quite improbable that a random error would
  26. cause one instruction to mutate into another valid instruction. If
  27. it does turn out to be probable, then by simply making the distance
  28. between two instructions greater you can reduce the chance of random
  29. mutations to arbitarily low figures.
  30. For example, in Machine Code MKI, we have the following four instructions:
  31.  
  32.     Instruction        Binary Code
  33.  
  34.     ADD               00
  35.     MULT               01
  36.     STORE               10
  37.     GET               11
  38.  
  39. With this, any mutation would generate another valid code, which is
  40. not very good. Now consider Machine Code MKII:
  41.  
  42.     ADD               00110011
  43.     MULT               11001100
  44.     STORE               11000011
  45.     GET               00111100
  46.  
  47. With this code, at least 4 bits have to be corrupted *in the right way*
  48. for another valid instruction to be produced. 
  49. This is really getting quite unlikely. The whole thing is a form of
  50. error detection, and this really is a very basic version. 
  51.  
  52. : >the error correcting mechanisms in living things are fairly poor.
  53. : >Simply using a good mathematically based error correction code in the
  54. : >nanomachine's internal program could reduce the "mutation" rate so low
  55. : >that a mutation event is expected only once every few billion years or
  56. : 
  57. : I'd have to see some figures before I accept this.
  58.  
  59. Using methods as described above, or better ones, you can set the
  60. mutation rate to an arbitarily low figure. How about one mutation
  61. per 10**15 years? What about one per 10**20? You can just keep on
  62. going. Obviously you trade off a bit of storage space for things
  63. like this. TANSTAAFL.
  64.  
  65. Steve
  66. -- 
  67. ------------------------------------------------------------------------------
  68. Steve Strong - email srs@oasis.icl.co.uk      | Wasn't me. I didn't say that.
  69.                voice 44 344 424842 extn 2279  | Definitely got the wrong guy.
  70. ------------------------------------------------------------------------------
  71.