Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!bcm!dimacs.rutgers.edu!aramis.rutgers.edu!athos.rutgers.edu!nanotech From: cphoenix@csli.stanford.edu (Chris Phoenix) Newsgroups: sci.nanotech Subject: Re: Is this stuff for real? Keywords: reality nanotech questions Message-ID: Date: 24 Mar 91 23:25:23 GMT Sender: nanotech@athos.rutgers.edu Organization: Center for the Study of Language and Information, Stanford U. Lines: 71 Approved: nanotech@aramis.rutgers.edu In article bsmart@bsmart.tti.com (Bsmart) writes: > >In article , >cphoenix@csli.stanford.edu (Chris Phoenix) writes: >> replicating the machine. However, computer memory has one feature >> that the DNA doesn't: it has a computer. > >I think part of the problem is that the point of nanomachines is that >they operate at the molecular (or even submolecular) level, and are >presumably implemented on a similar scale. Nanocomputers probably won't >work like the digital electronic computers we're familiar with today; ... > Now, there's no reason why a mechanical computer can't be >digital in its operation ... I guess I should have thought more about the computer I was talking about. Yes, I was assuming a digital computer, with distinct memory and processor. I think Drexler's rod-logic computer qualifies. I wasn't saying "nanomachines will not mutate," but rather "It's possible to build a nanomachine which will not mutate as a cell does"--that is, the "genetic material" (computer memory) will not make undetected changes. But maybe I should have thought more about the processor... > ... but the fact remains that computers (or any other kind of gadgetry) >implemented on a molecular scale will be subject to chemical and >radiation interference at the same scale. Notice, I said *undetected* changes. I don't deny errors will happen--what I was trying to point out is that if they happen, you can almost certainly detect them. And you can make that "almost" as close to "always" as you want. >Perhaps the >error could be corrected by some kind of detection scheme (we do it with >memory errors all the time on the macro scale) but if the error were >severe enough, or if it happened to hit the error-correcting part of the >nanocomputer, then on come the red lights and it no longer behaves like >a computer. In my scheme, "on come the red lights" means "the nanomachine turns itself off." This is the best scenario. The one we're trying to avoid is where there's an error and the red lights don't come on. We both need to think about what "the error-correcting part of the nanocomputer" means. I can see two possibilities: 1) a certain area of memory; 2) a certain part of the processor. I don't think 1) needs any special consideration. Consider a correcting scheme in which everything in memory is stored three times. The computer reads all three locations each time it wants a byte, and if they disagree it turns off the machine. Now, which of the three copies is the "error-correcting part?" In other words, there needn't be a "critical" part of memory such that if it's damaged the scheme won't detect the error. 2) may be more worrysome. I would almost class this under the "hardware errors" that I talked about in my first post--the ones that don't involve "mutation" of the "information" but can still cause problems. Here we're getting into areas I don't know about, like circuit testing. The question is whether it's possible for a computer's hardware to fail so that it makes mistakes, but it doesn't "know" it's faulty, and the fault can't be detected from outside. Currently, CPUs are hitting the market that have errors in them--I think I read about one that would crash if it tried to read the last 36 bytes of a segment! How do you test for an error like that? And what if the only code that filled a segment was the machine-copying code? Again, anyone who knows enough, please fill in! I find it really unlikely that such an error would be self-propagating, ie that a hardware bug in the computer could cause copies to be built with exactly the same hardware bug in the computer. (The case of the sloppy arm building another sloppy arm is probably more likely, because there the cause and effect are both mechanical, whereas with the computer error the effect is still mechanical but the cause is a logical error in running a program--the only way such a bug can propagate is by changing the execution of a program.) But I'm starting to handwave here, so I'll stop.