http://qs1969.pair.com?node_id=219419


in reply to MOPT-01 - assumptions and spaces

Great post!

I'm curious about that aside though.

they just act as the selection function in a very slow genetic algorithm that evolves a set of rules around a desired set of features

I thought that was what programming was about, taking the computer's way of processing and applying it to what you want done. I'm self-taught, so maybe I missed something really big in the course of my learning? Could you clarify that part for a poor confused monk? Thanks.

-BronzeWing


Perl Monks do it more than one way.

Replies are listed 'Best First'.
Re2: MOPT-01 - assumptions and spaces
by mstone (Deacon) on Dec 13, 2002 at 08:11 UTC

    When you use genetic algorithms, you don't 'plan' anything. You start with a large set of random code sequences, and test them to see which ones come closest to the answer you want. Then you throw away all but, say, the best 1% of the set, and build a new large set out of random permutations of those survivors. After a few hundred passes through the loop, you end up with code that performs the desired function--often surprisingly well--but whose workings are almost always incomprehensible to the human mind.

    The best analogy I've seen for genetic algorithms is: "teaching monkeys to drive a bus by putting each one behind the wheel for five minutes, then breeding a new tribe from the two who make the bus move the farthest."

    Genetic-style coders have practices like 'shotgun debugging': changing parts of the code more or less at random, then running the program again to see if the bug went away. It works.. sometimes.. unless it screws up the code so completely that you have to go back and rewrite everything from scratch. But in those cases where it does work, the resulting code usually ends up so badly organized that no one ever wants to touch it again.

    Whenever you hear someone say, "yeah, that program sucks, but we don't dare change it," you're in the presence of code that's evolved randomly, rather than being planned.

    Programmers, OTOH, start by doing a whole lot of bookkeeping to figure out exactly what is the program supposed to do.. and I don't mean just "crunch numbers." You have to have a good, solid answer for at least the following questions:

    • What are the inputs and outputs?
    • Where do the inputs come from?
    • Where do the outputs go?
    • What are the acceptable values for the inputs and outputs, and what values are forbidden?
    • How do we guarantee that every input and output meets its validity constraints?
    • What does the program do if it finds a forbidden value?
    • What algorithm will we use to turn the inputs into outputs?
    • How do we guarantee that the algorithm always generates correct values, and always terminates in a reasonable amount of time?

    and for any real project, you'll find more.

    If you really have everything squared away, you can write a mathematical proof that shows your program will always Do The Right Thing.

    Professor Donald E. Knuth is one of the great-granddaddies of "knowing what you're doing"-style programming, and is credited with having sent someone a piece of code with a note saying, "Beware of bugs in the above code; I have only proved it correct, not tried it.'" Just for reference, Knuth is also the creator of TeX, a typesetting language that dominates much of the professional print industry. The version number of TeX increases by one digit of Pi every time someone finds, and Knuth fixes, a bug. The current version number of TeX is 3.14159, which ain't bad for a program that's been in professional use since the late 70s. As far as anyone knows, the last bug in TeX was found and removed on November 27, 1985.

    That's programming. ;-)

      Okay, I get it now... I guess that puts me somewhere just past shotgun debugging but not quite at planning ahead. At least now I know I have lots of room for improvement *grin*. Thanks for the explanation!

      -BronzeWing


      Perl Monks do it more than one way.