Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!aramis.rutgers.edu!gpu.utcs.utoronto.ca!craig From: craig@GPU.UTCS.UTORONTO.CA (Craig Hubley) Newsgroups: sci.nanotech Subject: Re: Barriers and Bottlenecks Message-ID: <8904220141.AA08261@aramis.rutgers.edu> Date: 21 Apr 89 20:32:54 GMT References: <8904180627.AA19496@athos.rutgers.edu> Sender: nanotech@aramis.rutgers.edu Organization: University of Toronto Computing Services Lines: 79 Approved: nanotech@aramis.rutgers.edu In article <8904180627.AA19496@athos.rutgers.edu> doom@PORTIA.STANFORD.EDU (Joseph Brenner) writes: >that humans can't overcome. For example, it *could* be that we're not >smart enough to write programs as smart as we are. NOTE: I HAVE NO >INTEREST IN DEFENDING THIS EXAMPLE. I don't think this is a great >place to debate the feasibility of artificial intelligence. One important thing to point out is that no *one* human is smart enough... it has taken the collective effort of millions in order to get to the present... no one person could have leaped over those thousands of years to present a working brain program, although writing was invented in 5000 BC or so, and no new technology is required to write the program... all development in between has been conceptual bootstrapping, providing theories, mirrors and hardware against which to test all such ideas. Nor can one mammal cell reproduce itself - that cell is part of a larger mechanism that can, however, reproduce. So far as I can see, this negates any idea that humans can't construct something smarter than a single human brain - it's simply not a Goedelian affair, since a single human brain is not what's constructing the 'smarter' thing. The same applies to any argument that collectively-developed capabilties are in some way limited by the capabilities of their smallest distinguishable part... as intelligence is emergent from neuron activity, so is AI emergent from research activity... maybe. But there's no barrier here... it seems to me that there is simply no way to judge complexity until we run right into it. >There is another way in which (2) could be wrong: there could be >one or more bottlenecks to the development of nanotech which will >slow things down radically (diamond is an unstable form of graphite, >but the transformation is so slow no one cares). The future may >not be described by a smoothly rising curve: instead, imagine a >series of steep curves "punctuated" by plateaus. The curve has always been an approximation... in fact 'punctuated equilibrium' which is what physical anthropologists call what you describe, is the dominant form of evolution theory... this week. >For example, consider genetic proofreading. Drexler considers it a >fairly simple process: each assembler meanders around until it finds >a DNA strand. It moves back and forth along it until it has the entire >structure in memory. It compares the structure to the expected >structure, and chooses to kill the cell if it differs (due to mutation or >infection). There's an important caveat: the assembler must be able >to distinguish between the host's damaged cells, and the cells of >another human being (or any other plant or animal) otherwise it >would become a deadly virus if it escaped the host and wound up in >someone else's body. Exactly how tough is this pattern recognition >job? I don't think we know enough biology to say for sure. >Note that this is a very simple application compared to a full-featured >cell repair machine. > >If there are problems in the development of atomic scale manipulation, >nanocomputers, self-replication, or a number of other areas it would be >devastating for the prospects of Drexler-style nanotech. If you >assume the problems do exist, what would they be like? Programming the little beasties is indeed a difficult problem... thankfully the biological mechanism is not based only on linear programs at all, but on short segments that generate multiple mechanisms that are intended to work in parallel - work begins only when all parts are assembled. The short instruction sequences help to keep down errors, the need for all parts to be present avoids wrongheaded activity, and the complete failure of the process should one part be absent or defective (usually), serve to: 1. cut losses incurred by errors (only one part need be regenerated) 2. reduce errors through short command sequences 3. reduce the possibility of not-obviously-defective parts by keeping them simple, thus failures are easier to detect 4. promote efficiency through parallelism Note that nature discovered ICs and object-oriented programming long before we did! Anyone who intends to write Fortran in DNA pairs had better be locked up now, before they destroy the world. 0.1 :-) Craig Hubley -- Craig Hubley ------------------------------------- craig@gpu.utcs.toronto.edu "Lead, follow, or get out of the way" mnetor!utgpu!craig@uunet.UU.NET ------------------------------------- {allegra,bnr-vpa,cbosgd,decvax,ihnp4,mnetor,utzoo,utcsri}!utgpu!craig