Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!nanotech From: 71450.1773@compuserve.com (Steven B. Harris) Newsgroups: sci.nanotech Subject: Hardware Error Checking Message-ID: Date: 16 Mar 91 03:31:36 GMT Sender: nanotech@athos.rutgers.edu Lines: 70 Approved: nanotech@aramis.rutgers.edu Chris Phoenix reminds us that a spontaneous error in the con- struction of a self-replicating machine might conceivably: 1) Cause changes in construction of the next (third) generation that cause the error to be exactly perpetuated "extragenetically" (i.e., without a software change). 2) Impair the ability of the mutant machine to sense the error in next (third) generation machines. 3) Along the way, screw up the function of the machine so as to make it dangerous. Mutations that meet all these criteria are the nasty ones. How does the *initial* mutant machine escape the censorship of the previous generation of purebreds, we wonder? Perhaps the mutation is of such a subtle kind that it can only be found by destructive testing and comparison, and then only when compared with and tested by a "clean" unmutated line of machines. If so, I think the problem can still be dealt with. It seems to me that if necessary each new generation of machines can be held and scrutinized by and against _several_ previous genera- tions, and required to pass comparison tests against all of them (selected machines can be taken off the line for random destruc- tive comparison, as is done on modern assembly lines). If a generation passes comparison tests in this fashion, this does _not_ rule out a few 1st generation mutations that occur in machines that didn't happen to get taken apart, but it *does* rule out mutations in the parent machines of the form which meet the first criterion, or ALL the daughter machines would be affected. So if a generation passes the comparison test, you can release the parents (or if very conservative, the grand- parents), and allow the daughters to proceed with the next generation, which you then iteratively test. If, on the other hand, you find consistent mutations in a given generation, you destroy both it AND the parents, in much the same way that you may destroy a whole line of animals in stockbreeding when an unwanted genetic trait appears. Even mutations that do nothing but increase the mutation rate can be ferreted out (to an arbitrary degree) and destroyed by this method. All this, of course, is analogous to routines that check one program off against another, save that things are a bit more circuitous due to the fact that finished machines presumably can't be compared except by inference from a sample of their dissected progeny. Still, anything that can be done with software ought to able to be done with hardware-- they're the same thing, are they not? The lesson, I suppose, is that you can't necessarily catch all mutations if you have immediate-release free-floating repli- cators, like E. Coli. Thus, we may need tiny nanomachine "fac- tories" or at least storage facilities so that we can do our comparisons and go back and nip mutant lines in the bud before they go out into the world (one thinks of the thymus, with its tiered generations of cells in different phases of maturation). If we MUST do all with only one generic variety of replicator, it might be possible to have a lot of them interlock arms and build such a holding and checking facility out of themselves. Allow me to christen this a "breeding ball" (you heard it here first, folks). The term is suggestive of snake biology, but my visual metaphor for this is actually the ball of thousands of living workers which forms a nest of army ants. Steve Harris