Re: Basic reproductive architectures
- From: Rory McLean <rory@xxxxxxxxxxxxxxxxxx>
- Date: Tue, 27 Sep 2005 16:53:57 -0000
In article <11jhfrk4ll2sj62@xxxxxxxxxxxxxxxxxx>, James A. Donald
<URL:mailto:jamesd@xxxxxxxxxxx> wrote:
>
> --
> I know of one architecture whereby a system can
> completely reproduce itself, and it has a known capacity
> run amok.
>
> The basic architecture is that the system contains some
> form of data storage that contains a description of the
> complete system. To reproduce the complete system, the
> data is processed twice, once as code, to build the
> working machinery of the new system, and once as data,
> to produce a copy of the data in the original form for
> the new system.
It might be very important to consider that the system does not
include a description of the complete system, it includes a
description of a process to carry out, which will generate the
complete system.
This makes a very great difference in terms of what small changes
to the description (mutations?) will produce, and also how you
initially generate this description, by other than some
evolutionary process (you'll probably need a lot of simulation).
> Thus for example, DNA is copied to produce identical
> DNA, and also copied to produce RNA which is then
> processed to produce ... eventually producing proteins.
Mutation is an important part of this copying, and the filtering
out of non-viable results. Do we want to consider mutation of the
instructions in nanotech, except as something to be very careful
to prevent?
> Now suppose we want nanoassemblers to dismantle some
> random trash we have lying around, and produce something
> useful, say a pair of gloves. Since a pair of gloves is
> a fair bit larger than a nanoassembler, to do this in a
> reasonable time, our original nanoassembler must produce
> many copies of itself. Suppose it forgets that it is
> supposed to eventually stop producing copies of itself
> and switch to producing a pair of gloves?
You also need to consider how nanoassemblers recognise random
trash, whether this is pre-programmed in some way, or there is
some process by which they are instructed to treat something as
'trash'.
Compare this with how a cell with DNA decides that something in
its environment is suitable to be converted into more cells (and
DNA), and how multi-cellular organisms make this decision.
As for the run-away replication, this needs to be considered in
terms of the environment of other nanoassemblers, some of which
may be passing the raw materials around, or energy from some
source, or taking away heat and waste materials.
We call this failure 'cancer', and one of the defences against it
is other cells which look out for characteristic warnings of this
sort of behaviour, and kill the offending cells.
> Now I would feel a lot more comfortable if a
> nanoassembler could not independently produce a copy of
> itself - it just follows orders to produce whatever,
> which might be a copy of itself - it is dependent on the
> network for instructions as to what to do.
That is how cells work in a multi-cellular organism - they send
each other co-ordinating signals.
> So how do we
> imagine a network centric reproductive system, where the
> network is the computer, and the network is inherently
> resistant to viruses? If the network centric system is
> just the same thing on a larger scale, we are back to
> square one. Of course if the network as a whole is the
> thing to be reproduced, it is acceptable for it to
> ordinarily require human intervention each reproductive
> event, like an operating install that requires extensive
> human configuration, which would be intolerable if the
> reproductive event was producing nanocomponents.
Look at this as a a peer-to-peer network, where there is no fixed
master controller or server for all the clients to look to. The
various components look for various signals from their peers,
including control signals. If control signals cease then the
component negotiates to become a controller itself, to replace
the one that has disappeared. This is one way general-purpose
components can specialise, and adapt to the loss of previous
specialists.
If you consider this in a hierarchical way, being far enough from
a controller, but still receiving signals, might indicate the
boundary of some sort of other specialisation, say of function,
so a group of component might be an 'organ'. Compare slime moulds
with creatures with specialised organs.
Some communication might be much longer range, such as the
equivalent of nervous impulses as opposed to short-range
cell-to-cell chemical signals, and this is likely how overall
control of a multi-cell organism would be arranged. Very early on
at least one communication organ would develop, which accepts
instructions from the environment (say, humans), and distributes
this to the rest of the organism.
Reproduction of the whole organism might only be possible with
external instructions; rogue cells which cease to respond to
instructions, and might attempt to produce their own organism
will be aggressively dealt with.
If you want the network to be virus resistant, then it needs an
immune system, which recognises things within it which are not
under its control. Due to them not being its own components, or
raw or waste materials being internally transported.
Smart viruses will fake the correct inter-component signaling, or
otherwise evade the immune system's detection, so as not to be
recognised. Smart immune systems will have a wide range of ways
of testing for viruses.
> Is there some architecture that is inherently safer than
> parsing the data twice, once as data to be copied, once
> as code to be executed? Is, indeed, there any
> architecture that is not logically equivalent to parsing
> the data twice?
If you are thinking in computing terms, is this sort of a mix of
a compiler and an interpreter, where the interpreter executes the
code, and the compiler prepares it for later use? Does looking at
it like that, with regard to all the different computing software
architectures, get you anywhere?
> --digsig
> James A. Donald
> --
> http://www.jim.com
--
Rory McLean
rory@xxxxxxxxxxxxxxxxxx
.
- References:
- Basic reproductive architectures
- From: James A. Donald
- Basic reproductive architectures
- Prev by Date: Basic reproductive architectures
- Next by Date: Administrivia: Welcome to sci.nanotech!
- Previous by thread: Basic reproductive architectures
- Index(es):
Relevant Pages
|
|
