|
Hi Tim,
In the chapter you referenced, from Life, Itself there are several
different perspectives being used, and turned around, to show how even when the
aspect being focused on is different, the result is equivalent, in a machine.
For example, in the introduction to that chapter, (page 215):
Robert Rosen wrote: "Armed as we
now are with all of the special structure that pertains to the concept of a
mechanism, we will turn our full attention to the particular class of mechanisms
we called machines. As we recall, a machine is a mechanism, one
of whose models is a mathematical machine. Hence our concern is
with machines... as objects of scientific study.
Our first result will be to show explicitly that
machines in general admit relational descriptions. We will in
fact see in detail how the relational descriptions of machines arise from, and
are related to, their underlying "physics" as we have described it in the
preceding chapter. Once we have done this, it will become transparent how these
relational descriptions can be detached from that "physics". As such, we obtain
a formal encoding of pure organization, as a thing in
itself.
...The culmination of the present chapter will be
a theorem precisely characterizing machines' [organizational] limitations and a discussion of their
significance for biology, for physics, for technology, and even for mathematics
itself.
My treatment will be based on the distinction
between hardware and software, which as we have seen above (see
section 7E et seq.) is perhaps the essence of the concept of a mathematical
machine. Using the hypothesis that such a machine is a model, I will pull this
distinction back into the largest model, which exists by virtue of the fact that
a machine is a fortiori a mechanism. As we shall see in detail, we are
then enabled to decompose this largest model into a number of disjoint
functional units or operators (comprising the hardware) and that on which they
operate (the software). The functional units will be called
components; see section 5D above; their specific action on
software will be expressed in terms of inputs to these
components, and the entailment of corresponding
outputs.
[Note: Without all the context, this will be very difficult to
follow, however I thought it necessary to include enough of the references to
show how this is an instance of my father's peculiar talent for looking at
something in some very unusual ways which serve to illuminate aspects about it
that are not easy to find in a straightforward examination. This is also
unfortunately why it is not difficult to become disoriented. I have some
suggestions, to follow, which I hope will make it easier to decipher my father's
meaning...]
...Our result is: in a relational
description of a machine, there can be no closed paths [meaning that nothing is entailed from inside, which would constitute a
causal loop-- instead, everything is posited from outside the
system]. As we shall see, it is this result that
dooms the Cartesian metaphor, and much more than this, that exposes the
inadequacy of contemporary physics itself as a vehicle for encompassing biology,
and hence, material nature.
...My conclusion in not, however, entirely
negative. On the contrary, by virtue of the manner in which mechanisms fail to
encompass organisms, more suitable kind of encodings automatically suggest
themselves. These, as will be seen, involve limiting processes, which take us in
a natural way out of the world of mechanisms or simple systems, into a larger
world of complex systems."
OK-- let's look at what we've got here. So far we have
several terms that make references to definitions established prior to this
chapter. This is a critical issue. If you haven't read the
preceding discussion or refreshed your memory about it, prior to what is coming
up, you may entirely misinterpret what he's talking about (as per the Geologist
and rock-- which I wrote about on my website, incidentally, in the Robert Rosen
blog section). You need to know, for example, his difference between a
"machine" and a "mechanism". Mechanisms, as he uses the term, can and
do occur in living systems as components of subsystems, for instance,
whereas machines are human creations. Furthermore, his definition of a
"mathematical machine" is a particular kind of machine... so the contexts are
key and cannot be dispensed with if. The meaning flows from those
contexts. For brevity's sake, I'm having to do a lot of cutting and
splicing, but I encourage readers to refer to the original source material (this
book is still in print) and you will see for yourself that I am paraphrasing
those contexts for you, here. We continue on page 216:
Robert Rosen wrote: "We now turn
our attention to what we have called machines; ...systems such
that (1) all models are simulable, and (2) there is a model of the system that
is a mathematical machine.
Since a machine is a fortiori a mechanism, we have
seen that it must have a unique largest model and a family of smallest models.
The largest model, which we recall contains everything we can know about the
machine, is the direct sum of the smallest ones. Hence we can introduce, once
and for all, a set of states for the machine as a natural system, as we saw,
above. This much is true for any mechanism.
I will now invoke a further hypothesis that, in
the set of all models, there is one that is a mathematical machine. Indeed, in
what follows, I will use only one feature of this hypothesis, namely
that we can make a distinction between software and hardware.
We will see what this distinction means, when reflected in terms of the states
of the largest model.
Let us begin with a few words of heuristics.
Intuitively, we think of the hardware of a mathematical machine as a processor
of software. As such, this hardware has an inherent polarity;
it has an input or afferent side, and an output, or efferent side. This polarity
also reflects, and manifests, the flow of time in the system dynamics; the flow
is from input to output, from afferent to
efferent. With respect to the hardware, input and output are alike software, but
the outputs reflect the past and the inputs represent the
future.
We also observe that, in material terms, hardware
is open relative to software, and in general, conversely
[meaning that software is generally open
relative to hardware, too.]. When taken
together, they collectively constitute a single phase, in the Newtonian sense
(see section 4H above). The dynamics of the machine is simply the recursive
specification of next such phase in terms of present phase, as exemplified in
the notion of algorithm. From the trajectories of phase so
generated, we can extract or chronicle the transition from input to output,
which we identify with the operation of the machine. In a
sense, then, hardware constitutes tangent vectors to software, and
conversely."
So, he's saying that you can interchange these two in certain
ways and you will still have the distinction, in machines, between
hardware and software(similar to the way we can say that a person's good
qualities are "the virtues of their defects" or that their bad qualities are
"the defects of their virtues"-- there is a distinction between defects and
virtues which remains...)-- The software/hardware distinction is a
hallmark of non-complex systems and the lack of distinction between software and
hardware is one of the hallmarks of complex systems, particularly biological
systems. Also, bear in mind from the introduction to this chapter that he is
talking about aspects of machines in general, not about computers specifically,
AND at present he is discussing the mathematical machine "model" which has to be
at least one of the models in the largest set of all models which describe the
machine. So, he is talking about machine models, not machines directly, and he
has qualified his usage by referring to previous parts of the discussion,
earlier in the book. Perhaps you can see why I used to always say, "Dad, can you
rephrase this for me?"???
Let's press on, though and follow the arguments in this
chapter. I will ignore the mathematics that Tim quoted, because they
are a particular illustration of a particular part of this examination
and the larger meaning is revisited after the illustrations. On page
237, you will find:
Robert Rosen wrote: "Note also,
(though we will not be using it much in this volume) that the partitioning of
states I have described is closely related to the formal partitioning of
software into data and program (see section 7D above). The ability to make such
partitions is thus akin to programmability in a mathematical
machine. In an important sense, I am saying that the more constrained a
mechanism is, the more programmable; the more like an organism it appears. (The
reader should recall the arguments of Elsasser; see section 1A above.) Note also
that the idea of program is tied to the category of formal
causation. These are indeed highly significant observations, but it
would take us too far afield to pursue them in the present
context."
The conclusions in section 9G, starting on page 241, are
particularly useful for helping put all the preceding material into the
perspective he intended. I would always recommend the introductions and the
conclusions of each chapter to people's attention-- but especially to those
who aren't fluent in the technical details and the deep mathematics (and I
include myself in that category) because these parts of my father's
books discuss the seminal issues in prose. When people try to argue
from the illustrations (which is what the mathematics in his books typically
represent) and ignore the prose tying them together, they invariably go
astray. I won't reproduce the entire conclusion to this chapter, even
though it's one of his more entertaining pieces (the final passage
reads: "These few hints suggest how it is possible to leave the
world of mechanism without giving up science. Having provided them, I have
thereby rendered myself superfluous; readers are now in a position to proceed
for themselves and do everything that will be related henceforth on their
own." )(Right, Dad!)
On page 246, there is a nice short piece that, I hope, answers
Steve J.'s original question about efficient causation (which my
father characterized to me as "that which does the work or starts
the chain of entailment with regards to something in a
system"):
Robert Rosen wrote: "In short, [if we are dealing with machines] efficient causation of
something inside the system
is tied to final cause of
something outside the system. As Voltaire once succinctly put
it, "a clock argues a clockmaker," from which he then went on to conclude, by
extrapolation, "therefore a universe argues a God." This kind
of dialectic is in fact, as we have seen, inherent in the concept of a
machine... And, as I pointed out before, one of the main intentions of the
machine metaphor itself was to dispense with final causation entirely. Instead,
it inevitably reappears in a worse form than
before..."
In complex systems, such entailment chains are closed loops-- which
means that they are entailed from within. That is what is meant when my father
says complex systems are "closed to efficient causation". There is no
"clockmaker" as far as complexity is concerned, because complexity is
self-entailing when analyzed according to Aristotle's category of efficient
causality.
Judith Rosen
PS: I thought the accompanying photo of M.C. Escher's two hands
drawing one another into three dimensions would be of interest in this
discussion.
----- Original Message -----
|
Attachment:
escher10hands.jpg
Description: JPEG image
