Posted by
glen e. p. ropella-2 on
Sep 07, 2009; 4:10pm
URL: http://friam.383.s1.nabble.com/emergence-tp3586728p3598235.html
Yes, Robert's right. What seems to be missing from Russ' (arrogantly
named) "solution" is that there _are_ no interfaces that "get
implemented" and there _are_ no "entities" that emerge. Subjectively,
sure, we observe or measure patterns of interaction (often stable over
cosmological time scales) and we measure various coherent blobs behaving
in such a way that preserves identity for the blobs. But,
ontologically, such things are transient approximations...
idealizations... abstractions arrived at by the observer.
Even in his paper, Russ claims that emergence is fundamentally
abstraction (though "levels" is an irresponsible misnomer). And
abstraction is an attribute arrived at via measurement, not a property
that exists objectively.
In fact, we don't even need the observer/observed dichotomy for this to
be true. Any operation will be dependent on some and independent of
other aspects of its operand. I.e. any process will ignore some stuff
and be totally dependent on other stuff.
So, for example, an avalanche depends on type of snow but not on, say,
whether my cat scratches me. (There's not much snow where me and my cat
live. ;-) The range of an operator, as applied, is a measurement.
Emergence depends on the characteristics of the domain and range of some
(set of) operator(s).
In some cases, the operator is defined by a conscious observer and in
some cases, it isn't. Hence, Robert is right that (some) emergence is
(solely) in the eye of the observer. But in some cases, emergence is
"out there", particularly when the operator isn't defined by a conscious
observer, meaning Nick and Russ are right that (some) emergence exists
objectively.
It's important to note, however, that this CAN be orthogonal to
implementation. It is primarily a function of the domains and ranges of
the various operators being applied. In software, these are called
"aspects". And although aspect-oriented methods tend to take Russ'
approach and try to build a simple map between aspect and mechanism,
that's not necessary for any software. Aspects are defined by the
_usage_ patterns of the users, not the mechanisms that implement the
aspects. Yes, the two can be engineered to correspond; but they need
not be. A piece of software can exhibit aspects that are not (easily)
traceable to the organization of the mechanisms that implement them. In
fact, a piece of software can exhibit aspects that forever cease to
obtain when the users stop using the software in that way... and in some
cases, it only takes a tiny, invisible tweak in the way people use it...
hence the script-kiddie exploits and the blossoming domain of software
security.
That leads to a question: is an aspect _implemented_ if the software is
never used in a way that exhibits that aspect? Yes, it is implemented.
Does it emerge? No, because an aspect only shows up if the mechanism
is _used_ in a particular way. No usage pattern, no aspect, no
emergence. Hence, emergence is distinct from implementation, at least
in some identifiable cases. (This existence proof, disproves Russ'
claim, absent lots of semantic gymnastics surrounding the vague and
useless term "emergence".)
If the operator isn't applied, there is no emergent attribute. Hence,
emergence is not the dual of implementation. Emergence is the result of
applying particular operators to the mechanism. I.e. emergence is in
the eye of the beholder, even where the beholder is another mechanism.
(This extension allows one to hypothesize that there are many other
cases where implementation is distinct from emergence.)
Thus spake Robert Cordingley circa 09/07/2009 06:57 AM:
> IMHO, I thought 'to see', 'observations', 'arrangements' and 'order'
> were also largely 'in the eye of the beholder'! If emergence is ever to
> become a (part of) science, repeatable measurements (from verifiable
> observations) leading to one or more calculated parameters is the only
> way to bring 'emergence' in from the cold/limbo/twilight zone, where it
> appears to be right now. Statistical and/or structural pattern
> recognition <
http://en.wikipedia.org/wiki/Pattern_recognition> seem to
> be good places to start. (See also descriptive statistics)
> <
http://en.wikipedia.org/wiki/Descriptive_statistics> I don't know if
> this has yet been attempted/done but hope to hear otherwise. Perhaps
> it's just too hard.
--
glen e. p. ropella, 971-222-9095,
http://agent-based-modeling.com============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at
http://www.friam.org