|
Author
|
Topic: ID Predictions made by an Engineer
|
Irving
Member
Member # 535
|
posted 25. January 2003 22:06
quote:
I'm much more comfortable with a question like "What are the properties/attributes of elements and what are the aggregation/assembly/combinatorial processes (for lack of a better term for the stuff that puts elements together) that might lead to hierarchically modular (or scalable) architectures, and what kinds of elements and/or processes are unable to produce them?"
I might have some trouble with the concept that attributes of elements leads to architectures. This might pre-suppose an evolutionary bias. In my mind, architectures fall-out of requirements, and as requirements are allocated to sub-systems, the attrbutes of the subsystems are defined. Hence the architecture drives the attributes, rather than the attributes driving the architecture. However, I can see that this concept may pre-suppose an ID bias. How does one define an appraoch with neutral bias?
quote:
One of the things we've found in building applications using EAs that are used out there in the world to control real processes is that things like the kinds of mutations available ..., the way(s) in which recombination is allowed to occur ..., and how selection and replacement works ..., all affect what comes out the other end of the EA... So I'm wary of "RM & NS" by themselves as the focus of attention.
And from Janitor:
quote:
I don’t know if this can be done, Irving. The idea of varying and selecting from amongst the variations is so broad that I can’t imagine that there is much in the phenomenological world that couldn’t be “explained” on this principle.
Perhaps my focus upon RM & NS is a little specific in light of this context. However as a design methodology I see RM & NS as equivilant to ad hoc design. Though there are many flavors and extensions to RM & NS, are they all derivatives within the ad hoc design family?
[ 25. January 2003, 22:06: Message edited by: Irving ]
IP: Logged
|
|
RBH
Member
Member # 380
|
posted 25. January 2003 23:38
Irving wrote quote:
I might have some trouble with the concept that attributes of elements leads to architectures. This might pre-suppose an evolutionary bias. In my mind, architectures fall-out of requirements, and as requirements are allocated to sub-systems, the attrbutes of the subsystems are defined. Hence the architecture drives the attributes, rather than the attributes driving the architecture. However, I can see that this concept may pre-suppose an ID bias. How does one define an appraoch with neutral bias?
You're right about "leads." Perhaps "enables" is a better word: Are there properties of elements that more readily enable the kinds of architectures we're talking about?
As I know you know, what you've described is the top-down approach in engineering design and design analysis. Requirements (goals, intentions) lead to overall specifications which in turn generate designs, detailed specifications for parts (elements), and finally implementation - executing the design in matter and energy. But the question at issue seems to be whether there are elements and processes that in combination can produce those general kinds of scalable architectures or hierarchical modularity without the requirements and designs being pre-specified. In aid of that, we'd like to answer a (compound) question something like "Are elements with particular kinds of properties are necessary and/or are there representations that enable those sorts of architectures to emerge; and/or are there non-intentional combinatorial/construction processes that can aggregate those elements/representations in such a way as to produce that general kind of architecture?" (whew!)
In other words, rather than start by looking at something and trying to imagine what it might have been designed for in the sense of it executing some designer's intention, what I see as useful to address initially is the question of whether non-intentional processes, acting on elements not specifically formed for the purpose, can produce structures that display architectures like those that are generated according to classical engineering design procedures. That, after all, is the core question for using the analogy from human design as support for the plausibility of the ID conjecture in biology.
There appear to be three separable questions to be addressed in evaluating that analogy:
1. Do composite biological systems display the same kinds of architectures that are produced by human engineers employing human design approaches? That is, is there enough abstract architectural similarity to warrant further exploration? So far in this discussion we've assumed that there is, and I'm not sure we want to open this question here and now.
2. Does producing those kinds of architectures in either human or biological systems require that elements have certain kinds of enabling properties, do their representations have to have certain kinds of properties, and/or do the assembly processes have to have certain properties in order to allow those kinds of architectures to occur? This is what we have been discussing, more or less.
3. (Finally!) Do the elements of biological systems have those properties and/or representations, and/or do biological assembly processes have the necessary characteristics for those architectures to emerge 'naturally,' if the answer to Question 1 is Yes? This is where we might get some day! ![[Smile]](smile.gif)
I know those are very general, but they seem to me to be what require exploration in any serious attempt to evaluate the relevance of human design theory to biological structures.
RBH
[ 25. January 2003, 23:46: Message edited by: RBH ]
IP: Logged
|
|
Irving
Member
Member # 535
|
posted 26. January 2003 15:51
quote:
You're right about "leads." Perhaps "enables" is a better word: Are there properties of elements that more readily enable the kinds of architectures we're talking about?
Yes, "enables" is a better word; although, I'm not all that comfortable with it either...but this may be a distracting issue, so let me focus upon your other aspects.
quote:
1. Do composite biological systems display the same kinds of architectures that are produced by human engineers employing human design approaches? That is, is there enough abstract architectural similarity to warrant further exploration? So far in this discussion we've assumed that there is, and I'm not sure we want to open this question here and now.
I can agree here. There certainly seems to be applicability, but a premature jump into fray may be filled with too much subjectivity.
quote:
2. Does producing those kinds of architectures in either human or biological systems require that elements have certain kinds of enabling properties, do their representations have to have certain kinds of properties, and/or do the assembly processes have to have certain properties in order to allow those kinds of architectures to occur? This is what we have been discussing, more or less.
Here I would like to change "assembly processes" to design methodology. To be sure, assembly processes are important; however, to make a determination of Intelligent Activity the important issue is the identification of design artifacts that may indicate the design methodology. The assumption, of course, is that certain design methodologies are unique to Intelligent Activity. whereas Natural design methodologies are restricted to ad hoc and/or evolutionary methodologies. Therefore, if design methodologies are manifested in their resultant architectures, are certain architectures exclusive to Intelligent Activity?
So it is not so much do elements have properties that enable the architecture, but what element properties can or cannot be produced by non-intelligent design methods (reasonably speaking). Janitor speaks to some of these regarding design standards, protocols, interface specifications, etc... What are the hallmarks of ad hoc design (i.e. the use of GOTO's) versus the hallmarks of intelligently directed activity.
quote:
3. (Finally!) Do the elements of biological systems have those properties and/or representations, and/or do biological assembly processes have the necessary characteristics for those architectures to emerge 'naturally,' if the answer to Question 1 is Yes? This is where we might get some day!
Yes, as an end-state!
quote:
I know those are very general, but they seem to me to be what require exploration in any serious attempt to evaluate the relevance of human design theory to biological structures.
I know I'm being a little picky, but I think we can agree that if biological design is determined to be the result of intelligent activity, it wouldn't be Human Design Theory per se. So it's not exactly the relevance of Human Design to biological structures, but rather can natural design processes produce biological structures. However, I'm interested in more that just biological structures...as I'd like to be able to pick out Intelligently Design Activity from seemingly random cyberspace phenomena.
Irving
IP: Logged
|
|
kyle7
Member
Member # 191
|
posted 27. January 2003 05:48
Irving,
I don't mind discussing the issue of scalability under this topic, though I have some suggestions. The ideas you are trying to convey seem to hold promise, but it would help me if you would give a definition of scalibility and provide clear examples both in engineering and biology (I never did like the word scalibility given the ambiguity of the term). I know you want to start off simply first and develop the ideas, but I think it would be good to expand on it directly. I will try here.
- 1) Scalability requires forethought and intelligence. If Darwinian evolution did occur we should find a multitude of "dead ends", where partial systems exist serving a quasi-function or no function. We find this rarely (if any) in nature so this supports design. I know that some may try to give examples of the redundancy in the genome but I would not consider this a good counter argument. The need for redundancy is understandable given the need for high accuracy in reproduction. Also, the notion of "junk DNA" is questionable. A lot of supposed "junk DNA" has been found to perform useful purposes. I think biologists will find less "junk DNA" as time progresses, though this is presently debateable.
- 2) There is a significant difference in systems that are intelligently designed as a whole and systems where the design evolves over time with different requirements and specifications. The latter are less unified with duplicate systems and many "add ons" whereas the former are more efficient without duplication and unnecessary redundancy. For example in engineering, a tank may be designed all at once so that the systems are highly integrated and operate smoothly. Another older tank may have evolved over time, where new systems are added to the design. For example, new armor may need to be added. A new electromagnetic gun may be added, which would require an auxiliary power system. A larger engine may be required for the added weight. A new computer system may be added requiring another power system. An auxiliary cooling system may be added for the electromagnetic gun. Additionally armor and structure may be added to protect the new systems. Darwinian evolution should be like the old tank with duplicate systems, which does not seem to be the case. Why should there be just one brain? Should not there be many brains operating in tandem? Would there not be several hearts operating synchronously? The ease that Neo-Darwinian evolution supposedly develops new systems lends support to this issue related to scalibility.
- 3) The issue of scalability also relates with my original post. When you add on new systems to a highly coupled system there are numerous and specified changes that are required to enable the functionality of the new system. This means that there are numerous and specified mutations required for a functional new system. The catch 22 is that without the functional system there is no reason that natural selection should favor the mutated genotypes required in order for the new system to develop. In addition, the issue of phase space or design space is relevant. When you have a large number of specified mutations required, the probability of this happening is beyond the universal probability bound (1E-150).
Irving, you say the following:
quote:
Rm & NS can make a good case that it can arrive at an "operable" (living) component, but it cannot arrive at a scalable component of proper complexity since the scalable requirement is outside the selection environment during the evolution of the individual component. I would also make the case that a multitude of individually evolved components (solid state images) would better match the individual selection environment better than this scalable image. Therefore it is quite likely that RM & NS would reject a potentially scalable component in favor of a better individually-matched non-scalable component.
I am a little confused by what you mean by scalable. Again, this term is one that does not have a clear definition even in engineering. For me, it seems to muddle my understanding of what you are trying to say. The definition of scalable from my dictionary is the following :
quote:
Scalable: capable of being scaled: the scalable slope of a mountain. [SCALE 3 + able]
SCALE 3: a succession or progression of steps or degrees.
I actually need an engineering dictionary for a better definition of "scalability", but the basis of the term seems to be about progressive steps which would seem to be in line with what Darwinists seem to argue. Maybe you need a different term to better convey your meaning. Again, I always found the term "scalability" ambiguous, though the term can be useful if we present a clear definition.
I started writing this a while ago in my spare time and the thread has had many new posts. I will post this with some additional comments.
Neil A. Wells: Your example of the intricate paving stones eventually being found to be of natural origin does not present ID with a problem. The whole idea of intelligent design is to establish a probability landscape of the artifact in question. This probability landscape should include all known and possible explanations. The power of Dembski's method is that both Neo-Darwinists and ID proponents are able to use it to argue their cases.
RBH,
Your example of the L-system is an example of how Neo-Darwinists put forth abstractions. Specifically evolutionary scenarios are presented which are more in line to analogies for they fail to capture the physics of actual biological systems. Abstractions at times may be beneficial in leading to the details, but without the details abstractions are not real evidence. This is a problem with many of the EA programs, for it is hard to see the value in them if they don't actually simulate the physics of the biology.
Darwin, D.
If all you are doing is playing a "whack-a-mole" game then you should leave this forum - specifically my thread. On the other hand, if you are willing to present something useful to the discussion then I would invite you to participate.
Abstraction: 1) an impractical idea; something visionary and unrealistic. 2) the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects or actual instances.
I would like to commend you all on the many fine posts! Sorry, my time has limited my participation. Thanks.
IP: Logged
|
|
Irving
Member
Member # 535
|
posted 28. January 2003 07:37
Thanks kyle7 for allowing me to develop this issue in your thread!
quote:
I am a little confused by what you mean by scalable. Again, this term is one that does not have a clear definition even in engineering.
I agree that the term's defintion is not always clear within engineering, hence my attempt to develop the definition. Here are a few definitions from industry.
1. From www.dictionary.com
quote:
How well a solution to some problem will work when the size of the problem increases.
2. From the Software Engineering Institute
quote:
The ease with which a system or component can be modified to fit the problem area.
While these are good definitions, because they attempt to cover all bases, they don't offer enough specificity to do much work. Here is a definition that more closely relates to my working defintion.
3. From search390.com
quote:
1) It is the ability of a computer application or product (hardware or software) to continue to function well when it (or its context) is changed in size or volume in order to meet a user need. Typically, the rescaling is to a larger size or volume. The rescaling can be of the product itself (for example, a line of computer systems of different sizes in terms of storage, RAM, and so forth) or in the scalable object's movement to a new context (for example, a new operating system).
An example: John Young in his book Exploring IBM's New-Age Mainframes describes the RS/6000 SP operating system as one that delivers scalability ("the ability to retain performance levels when adding additional processors"). Another example: In printing, scalable fonts are fonts that can be resized smaller or larger using software without losing quality.
Allow me a slight twist on this defintion. I attempted to address both the volume and size issue in my examples. For simplicity I restricted my volume discussion to replications of a single component to fill the problem space. My circuit board image attempted to illustrate this as a web-background component that can be tiled to fill a space of any size seamlessly. The Space Invader's example also attempted to address this with a more complex and realized example. Think of a parallel computing architecture in which additional CPUs can be added to increase performance.
I leveraged off the volume issue in attempting to address the size issue. In my "fern" example I attempted to illustrate the design of the "leaf" being sized-up to be the design of the "branch," and then the design sized-up again to be used as the "plant."
While the term scalability has many additional derivatives and meanings, I had hoped to focus on just two (or maybe even one) aspect to limit the scope of the discussion.
quote:
The issue of scalability also relates with my original post. When you add on new systems to a highly coupled system there are numerous and specified changes that are required to enable the functionality of the new system.
Yes, which is why I'd hoped you would allow this discussion under your topic.
You point concerning abstraction and real-world instantiation is directly tied to what I'm calling "the integration problem." When you consider all the possible instantiations of heiarchical and modular architectures,it seems a little daunting in where to start. I therefore thought it prudent to drastically limit the discussion space as much as possible by focusing directly on a single style of architecture--a scalable one using replicated components/design.
Your tank analogy also speaks to my contention that the instantiation of the end product is directly attributable to the design methodology used.
All of this returns to a central issue of defining the difference between ad hoc designs and other design methodologies. It is my contention that a primary discriminator is in how different methodologies treat requirements. Ad hoc design addresses requirements one at a time, whereas other methodologies aggregate requirements (existing and future). It is in the aggregation of requirements that development standards (interface specs, protocols, etc...) are derived. These standards then become sub-system specifications. Recognize that not all sub-system specifications are the result of aggregation, only some of them. Hence functional requirements may be allocated into modular sub-systems; however, system-wide integration requirements are distinct from purely functional specifications.
So now we arrive here:
quote:
I actually need an engineering dictionary for a better definition of "scalability", but the basis of the term seems to be about progressive steps which would seem to be in line with what Darwinists seem to argue.
The basis of ad hoc design is progressive steps that are in line with Darwinism. The question is what architectures can a progressive step development produce? To simplify the analysis I've attempted to set the functional specifications of modules to the same value (replication) so that the interface specification is in isolation.
The issue then is understanding a volume scaled architecture in the context of a progressive step development and when requirements are fed into the design methodology. Let's look at a simple two step progression.
1. Develop the functional component
2. Volume scale, by adding a duplicate of the functional component
The problem then is that the integration requirements are introduced in step two, not in step one. You can't just duplicate the component in step two and then modify the components since the dual-component system doesn't even get off the ground.
IP: Logged
|
|
Janitor@MIT
Member
Member # 125
|
posted 29. January 2003 11:32
Its interesting that a quick web-search for “reusability + biological evolution” and “scalability + biological evolution” turned up very little of substance, other than the inevitable “software evolution” and hardware-software co-design articles, which address some of the integration problems Irving has mentioned. (And the works of Ceste & Doyle and Carlson & Doyle and their co-workers, which RBH knows I am particularly enamored with).
So even though I’ve stated quite confidently that scalability and reuse are universal to life, the biologists appear to be largely unaware of it! They are however aware of modularity and its advantages, they just haven’t quite made that connection in their minds yet. There is a vast literature in programming on these subjects however, where one will find algebraic and set-theoretic definitions of “module,” and Cousot & Cousot’s “abstract interpretations.” Very interesting to explore.
There is also some interesting work on “object-oriented” design of discrete, continuous, and hybrid systems (behavioral systems theory). The most interesting work that I ever found that relates biology to scalability is Hillol Kargupta’s work on biologically relevant representations. (I believe I’ve included references to all these in the ISCID Bibliography if you’re interested.) There is also this “value-added” analysis of modular design:
http://www.cs.virginia.edu/~sullivan/
publications/ESEC_FSE_2001.PDF
It might be interesting to compare and contrast “scalability” with Dembski and Behe’s “irreducible complexity.” I’ve always had a problem with “IC” because it seemed to me that designers design for “irreducible simplicity” or “reducible complexity,” exactly because of their intrinsic scalability/adaptability, etc. But I’m sure I don’t really understand “IC.” (Maybe they are compliments?)
IP: Logged
|
|
Irving
Member
Member # 535
|
posted 29. January 2003 19:44
quote:
So even though I’ve stated quite confidently that scalability and reuse are Universal to life, the biologists appear to be largely unaware of it! They are however aware of modularity and its advantages, they just haven’t quite made that connection in their minds yet. There is a vast literature in programming on these subjects however, where one will find algebraic and set-theoretic definitions of “module,” and Cousot & Cousot’s “abstract interpretations.” Very interesting to explore.
I have found this interesting also, but perhaps not surprising. Professions tend to get tunnel vision within their own discipline. I have found it surprising that most discussions I've seen regarding ID and complexity have been relegated to Biologists and Mathematicians, with very little input from Design Engineers. You'd think that a term like Intelligent Design would draw interest from folks who specialize in design!
I would also agree that more attention needs to be paid to modular design and modular structures including replication and scalability. Frances' and your links regarding modularity are interesting and probably deserve an entire series of threads on their own--the assumptions regarding integration and parcellization deserve a much richer treatment (and more critical examination) than what seems to have been accomplished.
In my own work I've dealt with these issues in regards to cyclomatic & essential complexity. Another metric which may offer some insight in a specified-function, modular design discussion is:
quote:
Module Design Complexity (iv(G)) is the complexity of the design-reduced module and reflects the complexity of the module's calling patterns to its immediate subordinate modules. This metric differentiates between modules which will seriously complicate the design of any program they are part of and modules which simply contain complex computational logic. It is the basis upon which program design and integration complexities are calculated. NIST Special Publication 500-235
Though I feel we need to walk before we run, and have attempted to reduce as much of the variables as much as possible. Hence a focus upon replication architectures with scalable components.
quote:
It might be interesting to compare and contrast “scalability” with Dembski and Behe’s “irreducible complexity.” I’ve always had a problem with “IC” because it seemed to me that designers design for “irreducible simplicity” or “reducible complexity,” exactly because of their intrinsic scalability/adaptability, etc.
But I’m sure I don’t really understand “IC.” (Maybe they are compliments?)
I've attempted to draw some parallels with Specified Complexity, and maybe some can be done regarding "IC." In thinking about IC, scalability, replication, modular desgin, a lot of things pop to mind...for instance is a recursive procedure an example of "IC," scalability or both? I suppose many a tangent could spin off at this point!
It is my suggestion that the interface/integration requirements (or their instantiation), of a scalable component (a module that fills a problem space through replication) is an example of Specified Complexity. If we consider this definiton:
quote:
Specified complexity is displayed by any object or event that has an extremely low probability of occurring by chance, and matches a discernable pattern.
In this case, the "discernable pattern" is the interface itself. In a progressive step scenario the integration requirement (selection criteria) is
not present during initial component development; therefore, its presence is purely due to chance. As the complexity of the integration requirement
increases, the probability of chance occurance decreases.
It may be considered that a scalable, replication architecture is irreducibly complex since at least two instances of the component are needed to instantiate the integration requirements. In addition, replication modules in such architectures are not functionally specific (not subject to functional parcellization). Granted this is only an off-the-cuff speculation...perhaps others can comment on its likelyhood.
Irving
[ 29. January 2003, 19:48: Message edited by: Irving ]
IP: Logged
|
|
Janitor@MIT
Member
Member # 125
|
posted 30. January 2003 15:28
As an experiment in cross-fertilization I should send Thomas McCabe Petra Gleiss' and Peter Stadler's e-mail addresses.
(In the spirit of John Doyle's and Walter Fontana's appeals for an interdisciplinary approach, engineering + biology.)
IP: Logged
|
|
|
Printer-friendly view of this topic