Re: Evolutionary rate

From: Jim Armstrong (jarmstro@qwest.net)
Date: Sat May 10 2003 - 12:13:28 EDT

  • Next message: Michael Roberts: "Re: Evolutionary rate"

    Iain -
    Thank you for the elaborations.
    I guess it is sufficient to say that my reaction to Behe's book against
    my particular background experience led me to a different conclusion at
    this point. I think you've done a pretty good job of articulating the
    reasons for coming to your conclusion.
    My sense at this point remains that the flow of the rather wide-open
    multi-possibility processes of nature are in some respects quite
    different than the point solution oriented processes of engineering. I
    realize that opens a whole different subject about humans as a point
    solution, but I'm not particularly interested in going there just now.

    Re "Toy Problem": Aha - I was acquainted with limited test cases. but
    not this particular term!

    Re "...it is pretty advanced technology compared with string a fixed
    number of NAND's together.": I can appreciate that. I did a little
    display decoder in the early days of NAND gates. It was fun learning
    about Karnaugh maps and deriving other logic functions from those simple
    building blocks!

    Re "Yes, I ran the United Devices software for a while ... These types
    of application are common when the problem you are dealing with can be
    easily split up into a number of independent workpackages (you are
    testing a set of molecules for activity against a particular protein,
    right?). The speed-up will be sub-linear on the number of processors,
    because they don't all run at the same speed, and different users will
    have different amounts of "idle time". However, they can indeed achieve
    great things because of the millions of computers used. But they don't
    interact."

        This was pretty much the substance of my original observation. My
    real point was not so much the SPEED (a point we wandered of into
    because of my parallel computing analogy), but the NUMBERS - the
    "millions of computers" notion. And, the "computers" of nature do interact.

    > Perhaps I wasn't clear. The authors know very well that very few
    > mutations are beneficial, but once a beneficial one has been found,
    > then Natural Selection acts to preserve the good ones and the bad ones
    > don't survive. That is all standard evolutionary theory & is why
    > their simulation worked.

    So far so good.

    > What I'm saying is that if you have a much bigger set of possibilities
    > to sample, though there may be exponentially more "good" mutations,
    > the number of "bad" ones will also be exponentially more, at a greater
    > rate.

    I'm stuck on this point. I hear what you say, but I need to explore a
    bit more about the validity of the statement about more "bad" than
    "good" mutations. I am not troubled by the statement if "bad" describes
    the whole set of mutations that do not move toward or fail to reach the
    desired objective. But that would not be a fair way to characterize the
    evolutionary process in nature wherein the "bad" are only those entities
    which can degrade or destroy a different and otherwise successful
    mutation. Mutations that in themselves are non-viable "products" simply
    don't count as either "good" or "bad" - they're neutral in the evolution
    process.

    What does "bad" mean in the context of your statement?

    > Given that nature can only sample (at random) a very small sample of
    > all the possibilities (e.g via mutation), then the probability of
    > your getting a good one decreases dramatically with the overall size
    > and complexity (hence number of possible genomes).

    It may be a very small sample in any absolute or relative sense, but the
    numbers of such samplings are still HUGE (my point)! And again, the
    conclusion seems sensitive to the particular definition of "bad".

    > Um, hope that makes it all a little clearer.
    > Iain

    Yes! Thanks! JimA



    This archive was generated by hypermail 2.1.4 : Sat May 10 2003 - 12:13:32 EDT