On Fri, Feb 22, 2013 at 9:11 PM, Gisle Vanem <gva...@broadpark.no> wrote: > Here is something interesting that you pythonistas might be > interested in: > http://www.primaryobjects.com/CMS/Article149.aspx > > """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 > program?
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 [1], 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. [4] 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. ChrisA [1] http://tools.ietf.org/html/rfc2795 [4] 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. -- http://mail.python.org/mailman/listinfo/python-list
