rosuav at gmail.com
Fri Feb 22 12:41:51 CET 2013
On Fri, Feb 22, 2013 at 9:11 PM, Gisle Vanem <gvanem at broadpark.no> wrote:
> Here is something interesting that you pythonistas might be
> interested in:
> """This article describes an experiment to produce an AI program, capable of
> developing its own programs, using a genetic algorithm implementation with
> self-modifying and self-improving code. """
> The above experimental BrainF** language was written using C#. So who will
> be the first to make an AI-language in Python that generates it's own
That's not artificial intelligence, though. It's artificial program
generation based on a known target output. The "Fitness" calculation
is based on a specific target string. This is fine for devising a
program that will produce the entire works of Shakespeare, since there
is a target string for that (actually, several targets, plus you have
to work out whether you want the works of Shakespeare or the works of
some guy named Bacon... mmm bacon), but I suggest that a more
sophisticated and useful goal be implemented.
As suggested in RFC 2795 , the resources required to implement such
a project would also have other uses. Like the Infinite Improbability
Drive, this is power that we should put to a very practical use...
such as ending world poverty, curing disease, or most importantly,
writing a good situation comedy for television. 
This program generation technique is highly superior to the technique
of taking a number of highly paid programmers, supplying them with
coffee and Internets, and expecting them to produce the code you want.
Empirical evidence has shown repeatedly that highly paid programmers
will produce bugs, and entire programming subindustries exist to
manage these bugs; instead, use of virtualized monkeys running on
innumerable cores of a massively parallel system (note, incidentally,
that RFC 2795 was careful specifically to not preclude implementations
involving subatomic monkeys or multiple universes - I'm sure
virtualization is one of those, but I'm not sure which), with
consequent massive increase of throughput and output.
Please proceed with this implementation, but do keep RFC 2795 in mind.
You want to remain interoperable, which means following the standards.
 The author of RFC 2795 was unable to find a reference in any issue
of TV Guide published between 1956 and the date of that document.
More information about the Python-list