The Real Weasel in JavaScript

I set up a page taking a first pass at providing a “weasel” program that follows the description Richard Dawkins gave in “The Blind Watchmaker”. It is done using a not well-behaved JavaScript routine, but as this was my first JavaScript coding of any sort, I figure refinement can come later. See it here. New version here. [Now also integrated into the main AntiEvolution.org CMS.]

One of the things that the page aims to debunk is the long-running falsehood that “weasel” (and every other form of evolutionary computation) must get its relative improvement over random search by somehow “locking in” parts of solutions that match a known target. William Dembski is the most persistent of people peddling this error, even though he was handed effective notice of its falsity over eight years ago. To that end, the “weasel” I wrote not only does not “lock” individual characters, but you can verify that it does not lock individual characters against mutation. You can set higher mutation rates and smaller population sizes to find values that cause “weasel” to sometimes step back to having worse performance in one generation than it had in the generation just previous. A simple verification can be had by setting the default target string, a population of 30, and a mutation rate of 8% per character. Run that several times, and most times you will see at least one generation that had a stepback in performance.

Dembski and others make much of the fact that the few lines Dawkins used to illustrate output from his “weasel” don’t show an instance of a stepback in performance. They insist that this means that Dawkins must have used a rule in his program that would not allow a stepback in performance, but that is simply induction gone wild and sloppy thinking. One can verify with my page that for reasonable mutation rates and population sizes, stepbacks are rare. Why is this? To get a stepback, every single string in a new population has to be have at least one less matching character than was present in its parent from the previous generation. The more strings that are generated in a new population, the smaller the probability that all of them will alter at least one of the already-matched characters from the parent string. So small population size is critical to observing stepbacks. Also, strings changing at least one already-matched character from the parent are less likely with lower mutation rates, so a high mutation rate is also critical to observing stepbacks. Neither of these conditions is didactically similar to the process that Dawkins wanted to make an analogy to, natural selection in biology.

I’ve already noted (and graphed) that there is a difference in performance between Dembski’s invention of an “oracle weasel” and what Dawkins’ description delivers. The “weasel” page of mine helps drive the point home by providing an interactive means for people to explore what a real implementation of what Dawkins described does.

Wesley R. Elsberry

Falconer. Interdisciplinary researcher: biology and computer science. Data scientist in real estate and econometrics. Blogger. Speaker. Photographer. Husband. Christian. Activist.

4 thoughts on “The Real Weasel in JavaScript

  • 2008/10/24 at 6:58 pm
    Permalink

    Wesley,

    I ran the simulation five times with Pop=20 and mut rate=8.0. The script hung on all five runs, at iteration numbers 156, 143, 136, 126, and 191.

    I’m running Firefox 3.0.3 on a Win XP Pro machine.

  • 2008/10/24 at 7:00 pm
    Permalink

    Same behavior with mut rates of 2.0 and 4.0 for Pop=20.

  • 2008/10/24 at 9:44 pm
    Permalink

    Thanks for taking the time to look. I’ve changed the way the JavaScript is handled so that it actually hands control back to the browser in between each generation, which hopefully will take care of the “hanging” problem.

    Try the new version here.

Comments are closed.