|
Author
|
Topic: Joshua A. Smart: On the Application of Irreducible Complexity
|
John Bracht
Member
Member # 5
|
posted 06. June 2003 02:32
And I've posted my response to RBH, also on the literature review forum (see RBH's link).
Suffice it to say, I think we may have had a terminology mix-up--I used the word "function" when I meant "instruction" (since instructions in Avida code for complex functions, they are interchangeable in my mind).
See the lit. review forum for the rest.
John
[ 06. June 2003, 02:51: Message edited by: John Bracht ]
IP: Logged
|
|
Mike Gene
Member
Member # 149
|
posted 06. June 2003 08:36
RBH,
Thanks for the links, but it would facilitate things quite nicely if someone could just list the number of parts and what they are (I did this with the flagellum, for example). Time is quite limited for me these days.
Argon,
I suppose RBH was thinking in terms of evolvability. But then we need to define evolvability.
IP: Logged
|
|
Mike Gene
Member
Member # 149
|
posted 06. June 2003 08:51
quote:
RBH: The other question at issue in the larger debate is whether objects that are determined by one or another means to be irreducibly complex can be constructed by naturalistic evolutionary processes. Smart occasionally slips into the assumption that they cannot, and that is not a settled question by any means. (emphasis added)
But there is a larger debate than this - whether objects that are determined by one or another means to be irreducibly complex were constructed by naturalistic evolutionary processes.
Part of the confusion also stems from the dual use of Darwinian explanation. On one hand, many think in purely abstract terms, using philosophy and mathematics to demonstrate something is possible or impossible. Yet on the other hand, a valid Darwinian explanation must apply to history. Darwinism, after all, is about origins and origins is part of history. The problem comes when the proponent of Darwinism commits a non sequitur, namely, after making a point about possibilities, they leap to conclusions about history.
I have long used to concept of IC while granting the possibility of its evolution. The utility of IC need not hinge on possibilities.
[ 06. June 2003, 08:52: Message edited by: Mike Gene ]
IP: Logged
|
|
Argon
Member
Member # 276
|
posted 06. June 2003 11:02
John Bracht writes, regarding discussions of the AVIDA programs & etc.:
quote:
There is no analogy in biology for the miracle appearance of fully formed, functional blocks.
There is no analogy anywhere for the "miracle appearance" of anything.
However, there are analogies within biology of exapted, rearranged, functional blocks and substructures. Note that Josh's "Evolutionary Method" for determining "core" IC components tacitly acknowledges such possibilities. A rather direct example is found in the programming of complex polyketide biosynthesis (and non-ribosomal peptide synthetic complexes).
Much of this work on PKS was pioneered by Chaitan Khosla (Standford). See Here.
(Now forming a core component of the technologies at Kosan Biosciences.)
A small overview of the system: Here.
A paper out of Chris Walsh's lab on similarities between polyketide synthases and non-ribosomal peptide synthases: Here. (Or here if the first link times out.)
Or search PubMed for: "polyketide synthase review"
[ 06. June 2003, 11:08: Message edited by: Argon ]
IP: Logged
|
|
RBH
Member
Member # 380
|
posted 06. June 2003 11:27
Mike Gene wrote quote:
Thanks for the links, but it would facilitate things quite nicely if someone could just list the number of parts and what they are (I did this with the flagellum, for example). Time is quite limited for me these days.
There are 23 such programs, each listed here. There's no more economical way, in terms of your time and my time, to list them. Two clicks and you're at whichever of the programs you wish to list.
RBH
IP: Logged
|
|
Joshua A. Smart
Member
Member # 773
|
posted 06. June 2003 11:35
I apologize that it has taken me a bit to reply; I was in the process of registering. For now I would mainly like to respond to some of the comments made by RBH. I will be out of town for the weekend but should have a chance to address other issues after that.
Conflation of "IC" and "Unevolvable"
I think one of the main things that would be beneficial here is to step back and look at what the purpose of the paper is. I wanted to spur those who are already convinced by the arguments of intelligent design in general, and irreducible complexity specifically, to apply those concepts to actual systems as opposed to simply arguing their validity.
Quite frankly, although Internet discussions can be beneficial and inspire new trains of thought, the number of "converts" either way is minimal (if existent). For those who are interested in seeing intelligent design become a respected part of science (of which I am one), data is the way to go. I assumed that IC meant a system was unevolvable because the paper was targeted towards those who felt that this was ultimately true.
"Contradiction" in discussion of EV
Now, I like detailed dissection as much as anyone. I often put the "anal" in analytic, and I enjoy it. In the case of the contradiction in my discussion of EV, though, I think it is unnecessary.
Here again, if the original intent is considered, the problem dissolves. The intent of the general example was nothing more than to demonstrate the methods being discussed for the purpose of clarification. Because the goal was clarity, I kept the example as simple as I felt I could. I didn't take the time to scrutinize the example to that level, because I thought looking at it that closely was pointless.
Actually, I think this argument takes us back to my original theme. I'm tired of the bickering over hypotheticals. (I am not trying to point fingers; I'm guilty of this too. I was "convicted" even as I realized what the paper was becoming.) I just don't think it's worth it. If my generic example were a real system, the discussion of its evolution (or lack thereof) would be a great one. But it's not. It's just an example.
While no one has posted it, I'm sure there are those who have noted the irony of my attempting to demonstrate ways to get away from generalities by using generic examples. I would like to mention here that I originally intended to use a specific system as well as a generic example. I did not have time to do this, however, as I was attempting to get the paper finished in time to submit it for the Polanyi contest.
Lenski
I'll just briefly mention Lenski here. I had not read the Lenski paper when my paper was posted. I now have a copy and I'm working on it. I'll just make a couple preliminary comments here.
1. I'm generally very wary of any in silico experiments. I think computers can be great for pointing us in a direction, but as for accurate demonstrations of biology, I have my doubts. The inability to replicate the complexity of "the real world," and the ease of front-loading information leave me very suspicious of any claims to have demonstrated biotic reality with a hard drive.
2. That said, I'm probably not the best person to discuss Lenski. I'm not a computer person at all, and in the end I might just leave this battle for more qualified people to fight.
Leaving aside that I understand that the Strict approach is ultimately necessary and only intended to indicate that at different stages less time-consuming approaches may be beneficial to get the ball rolling or focus discussion, those are my comments for now.
IP: Logged
|
|
Mike Gene
Member
Member # 149
|
posted 06. June 2003 11:42
RBH,
I'm not a computer programmer, thus your links are of no help to me. You say there are 23 programs. Does this mean you're talking about 23 "IC systems?" If so, pick one and identify all the parts.
IP: Logged
|
|
Pim van Meurs
Member
Member # 541
|
posted 06. June 2003 12:21
Micah: Let's not just take one paper, presented in the last few months, applied within in a static assemply architecture, and use it to completely disregard Josh's work.
I do not think that the intent is to disregard Josh's work. As others have pointed out Josh's approach seems to be quite refreshening. My intent was to see if the author would like to comment on the relevance of the recent work by Lenski et al as it applies to irreducible complexity.
Personally I consired Josh's paper one of the better ones on ID that I have read recently.
IP: Logged
|
|
Mike Gene
Member
Member # 149
|
posted 06. June 2003 12:23
Josh,
I just read your paper (a quick read) and I really liked it. I don't have the time for a systematic review, but I plan on posting serial tid bits over the next few days (and giving it another read).
IP: Logged
|
|
yersinia
Member
Member # 324
|
posted 06. June 2003 13:46
Hey Josh, glad you could join us:
Regarding the EV (Evolutionary Method), you wrote,
quote:
"Contradiction" in discussion of EV
Now, I like detailed dissection as much as anyone. I often put the "anal" in analytic, and I enjoy it. In the case of the contradiction in my discussion of EV, though, I think it is unnecessary. Here again, if the original intent is considered, the problem dissolves. The intent of the general example was nothing more than to demonstrate the methods being discussed for the purpose of clarification. Because the goal was clarity, I kept the example as simple as I felt I could. I didn't take the time to scrutinize the example to that level, because I thought looking at it that closely was pointless. Actually, I think this argument takes us back to my original theme. I'm tired of the bickering over hypotheticals. (I am not trying to point fingers; I'm guilty of this too. I was "convicted" even as I realized what the paper was becoming.) I just don't think it's worth it. If my generic example were a real system, the discussion of its evolution (or lack thereof) would be a great one. But it's not. It's just an example.
While no one has posted it, I'm sure there are those who have noted the irony of my attempting to demonstrate ways to get away from generalities by using generic examples. I would like to mention here that I originally intended to use a specific system as well as a generic example. I did not have time to do this, however, as I was attempting to get the paper finished in time to submit it for the Polanyi contest.
All this is reasonable; however I think that the reason we picked up on the "part A is required in X but not in Y" problem is that such cases are actually quite common.
E.g.:
(1) Hagemann factor is required for at least "good" function in human blood-clotting (lack is associated with miscarriage and other problems), but in whales it is absent entirely, the gene having been converted to a pseudogene (AE thread on blood clotting for refs).
(2) There are numerous examples of parts required in some flagella but not others; for example, in the Vibrio cholerae flagellum, additional required parts include (ref here):
[*] MotX, MotY
[*] FlhH & FlhG
...and apparently not required:
[*] the cap FliD
...plus they have many more Che genes than E. coli, although most of these may have overlapping functions
There are, I think, lots of other examples for blood-clotting, the immune system, the cilium, etc. So this particular challenge to IC is not just hypothetical.
Thanks, nic
IP: Logged
|
|
RBH
Member
Member # 380
|
posted 06. June 2003 18:04
For Mike Gene:
Case Study Genome: Run 130, ID 111
This is one of the 23 different assembly language programs that evolved to perform EQU in the 50 runs of the main experiment. (Recall that 124 additional such programs evolved to perform EQU in 36 control conditions of 10 runs each in which one or two of the intermediates were not selectively advantageous. So a total of 147 programs evolved to perform EQU under various conditions of availability of selectively advantageous intermediates.)
Each row is Instruction#, Instruction Code Letter, and Instruction Name. For example, Row 1 is Instruction #1, code r, h-alloc. That instruction in that position is IC for replication; if it is replaced by a null instruction the program cannot allocate memory at that point in the program loop. That particular instruction (#1) allocates a chunk of memory for an offspring.
1 r h-alloc
2 m dec
3 z set-flow
4 a nop-A
5 v mov-head
6 c nop-C
7 g push
8 m dec
9 c nop-C
10 i swap
11 q IO
12 q IO
13 p nand
14 t h-copy
15 q IO
16 p nand
17 q IO
18 c nop-C
19 p nand
20 c nop-C
21 t h-copy
22 l inc
23 e if-less
24 t h-copy
25 n add
26 c nop-C
27 o sub
28 g push
29 c nop-C
30 b nop-B
31 e if-less
32 a nop-A
33 m dec
34 q IO
35 d if-n-equ
36 t h-copy
37 q IO
38 c nop-C
39 p nand
40 t h-copy
41 i swap
42 p nand
43 q IO
44 f pop
45 p nand
46 g push
47 q IO
48 x get-head
49 u h-search
50 t h-copy
51 y if-label
52 c nop-C
53 u h-search
54 a nop-A
55 s h-divide
56 t h-copy
57 t h-copy
58 t h-copy
59 v mov-head
60 a nop-A
Irreducible Core for performance of EQU:
Instructions 2, 6, 11-12, 14-22, 24-26, 28-30, 34, 36-41, 43-47, 49, 53-54, and 59. Knocking out any one of those instructions by replacing it with a null instruction eliminates the program's ability to perform EQU.
Replication Irreducible Core
Instructions 1, 3-6, 49, 55, and 59. Knocking any one of them out eliminates the genome's ability to replicate. Instructions 6, 49, and 59 are also indispensable to replication; knocking any one of them out also eliminates the program's ability to perform EQU. Thus those three instructions ("genes") play a dual function in the program.
"Junk" instructions
Instructions 7-8, 10, 23, 31-32, 35, 48, 50-52, and 56-58 are "junk" instructions in the sense that knocking them out eliminates no function visible to selection.
RBH
Footnote to Micah: As I remarked to John a few months ago, I think sometime in February IIRC, the Avida architecture and instruction set is Turing-complete, meaning that it can instantiate a general-purpose computer. Note that it has all the components of a universal Turing machine; the only limitation on the Avida virtual machine's computing capabilities is imposed by the physical limits of the hardware available to run it on (memory). The architecture imposes no limitation on the computing capabilities of the Avida virtual machine.
IP: Logged
|
|
Argon
Member
Member # 276
|
posted 06. June 2003 18:46
A quick question for RBH when he returns:
IIRC, the programs can also perform additional functions that were used as intermediate, selective targets in the experiment. I'd find it interesting to see the steps to which these other functions map and whether they could be seen as subunits of the EDU function.
[ 06. June 2003, 18:48: Message edited by: Argon ]
IP: Logged
|
|
Mike Gene
Member
Member # 149
|
posted 06. June 2003 22:45
I'd like to thank RBH for the case study, as it helps to clarify things. But I'm having some real problems trying to apply IC to all this. Behe himself was quite explicit about the use of IC:
quote:
The first step in determining irreducible complexity is to specify both the function of the system and all system components. An irreducibly complex object will be composed of several parts, all of which contribute to the function....The second step in determining if a system is irreducibly complex is to ask if all the components are required for the function. - p. 42
Yet, as far as I can tell, no one has taken the first step regarding this computer run. First, I don’t recall anyone specifying what the function is. The function of the bacterial flagellum is to propel the bacteria (IDists did not arbitrarily define this function, it was defined by the community of experts who study the flagellum). Yet the function of this computer run is “EQU?” Do the 23 different programs carry out the same function?
Perhaps more problematic is that no one has specified the system components. Behe notes that a IC object will be composed of several parts. So IC 101 dictates that we specify the parts. But that’s where things get incredibly confused.
Looking through Run 130, and taking RBH’s list of instructions that are part of the “IC core,” one first gets the impression that we have a system with 34 parts (the sum total of the instructions), where each part is the instruction. Yet it turns out there is much redundancy here. For example, several times the same “part” is used multiple times. For example, part q (I’m using the instruction code letter) is used 8 different times. So does q count as one part or as eight parts?
Let’s make it one part. Thus, the list narrows to 14 parts - m,c,q,t,p,l,n,g,b,i,f,u,a,v. Not I problem, until you notice that many of the same parts RBH lists as part of the IC core are also included among the “junk.” In other words, even though RBH lists m, g, i, a, t, and c among the IC core, the same instructions also act as junk. Clearly, the instructions are not mapping cleanly to the concept of “parts” (or at least, not nearly as clean as gene products do).
So once again, the first step in an IC analysis is to identify the parts. What are the parts?
IP: Logged
|
|
RBH
Member
Member # 380
|
posted 06. June 2003 23:56
Argon,
The program above performs EQU, NOT, OR-N, OR, AND-N, and NOR. It does not perform NAND, AND, or XOR. It's difficult to say by inspecting the code which of those simpler functions are necessary components of the code that performs EQU, since in the evolution of the program various primitive instructions become involved in multiple functions. There's an example above - three instructions that are part of the replication code have been recruited to also participate in performing EQU. Thus individual instructions can have multiple roles, contributing to several functions, making program analysis difficult to nigh unto impossible.
There are other instances of this same kind of difficuly. For example, in the hardware evolution literature there was a flurry of publicity a year or so ago about a (hardware) radio receiver evolving under conditions that were selective for oscillation. In other outcomes of that same study, oscillators evolved as fairly simple circuits in the sense of using relatively few components of known properties that behaved appropriately under the selective conditions. The experimenters, experienced circuit designers themselves, could not figure out how the circuits did it. The outcomes of evolution in these kinds of studies are not simple, not obvious, and certainly not transparent in how they perform their behaviors.
Mike,
The principal function of the programs is to perform the logic operation EQU. All 23 programs (147 in the whole experiment, actually) evolved to perform EQU. The 23 that did so in the main condition are all different from one another. I don't know about the 124 that evolved in the various control conditions. As I noted above for the Case Study program, they all also performed some of the simpler logic operations, which are legitimately labeled "functions," too. But just as various kinds of bacteria evolved different sorts of flagella to perform the same principal function, motility, so the various Avida evolutionary runs evolved different programs to perform EQU.
Note, by the way, that once a program that performs EQU has evolved, the simpler logic operations can drop out of the competitive race - now be unrewarded - and the main function will persist in the population so long as it continues to be selectively advantageous. Way downstream, since they no longer confer selective advantage, those simpler functions may no longer be performed and thus won't be visible in the current population. We'd see no "precursors" of EQU in the extant population and we'd wonder where the heck our programs with the ability to perform EQU came from. And we could generate an "irreducibly complex programs that perform EQU can't evolve" conjecture, and we could challenge critics of our IC program conjecture to produce the exact pathway and tell us what those hypothetical precursors are. (And if they can't specify the precise pathway and the exact precursors, we could say "Neener neener neener!" ![[Wink]](wink.gif) )
As to parts, in constructing your list of 14 you have conflated "part" and "kind of part." 'q' is a "kind of part;" 'q as instruction #11' is a "part." It's like a brick pillar made of a slew of bricks piled up one on top of another. All the bricks are identical - all are the same "kind of part" - but pulling out the brick on the bottom of the pillar has a considerably different effect than pulling out the brick on top. They are different "parts" in the context of the structure. I take "part" in the program above to be coterminous with "Instruction #." Thus 'q as Instruction #11' is a different part from 'q as Instruction #11' or 'q as Instruction #17'. So the example above contains 60 "parts." In a computer program, the same primitive instruction used in different places is most definitely not redundancy!
RBH
IP: Logged
|
|
Rex Kerr
Member
Member # 632
|
posted 07. June 2003 00:35
It's worth pointing out that Avida's instructions are more like amino acids than proteins, in that each instruction is identical, and that position is important.
IP: Logged
|
|
|
Printer-friendly view of this topic