64 Comments

• Digg
• Bury

Thank you Tommstein! There are way to many .NET fans around here. .NET is _not_ the kind of platform useful for a Genetic Algorithm toolkit. Your Windows .NET GUI app will not be made better with this toolkit! It is just plain silly and mind boggling so many people think this is a good idea.

• Reply

• Digg
• Bury

I work professionally in evolutionary computation. This is more like genetic algorithms; there are distinct differences.Genetic algorithms are genotypic - operating on small bits of of information like DNAEP is phenotypic - operating on large characteristics like the size of you noseThere's a lot more to understand once you start to work on hard problems. It's not magic, but it has many benefits.

• Reply

• Digg
• Bury

I LOLed. (at whatsinaname's post)

• Reply

• Digg
• Bury

Ah, but you forgot to factor in the fact that 99.8% of digg users are idiots. It makes sense when you think about it, really, idiots using idiotic software. I thought slashdot.org was bad, but Jesus Christ, I'm not so sure which is more infested with idiots any more. So we've got our flaming queer Apple fanboy contingent, and now apparently we have a crew of .Net morons whose MCSEs were probably the crowning achievements in their lives. Why don't we just rename the site to "s**tty Technology Through The Eyes Of Retards Central" and be done with it.

• Reply

• Digg
• Bury

I agree that this is a cool idea, and one that doubtless has a vast number of potential uses. However, this kit only provides one of the components that seem to be critical to getting useful results from a GA system.First you have to be able to encode the thing(antennae, traffic, etc.) into a more regular form. This is where the "nucleotides" come in. Really, using ATGC rather than 1 and 0 for the encoding does not simplify it or make it any better, considering that, as a previous poster noted, the "nucleotides" themselves then just have to be encoded in binary for the computer to use them(16 bits!). The reason that they work so well in nature is that biological systems can recognize each base individually, not as a unique series of 1's and 0's. Using ATGC in this evolutionary algorithm seems to me just to be for looks, and would likely slow down the process.Then you have to do the selecting of superior offspring, which requires some certain criteria. This toolkit appears to be geared toward this step. If you know the criteria you're looking for, well, then this tool can evolve a set of data to match them, that much I agree to.The last part(though I suppose it is really linked to the second) is to have some kind of simulation that will tell you what you're looking for(or will test your offspring). In the case of NASA, they have the "Numerical Electromagnetic Code (NEC) antenna simulation software". That way, when their antenna design "evolves," they test it on the NEC and use its performance in their selection criteria. This, to me, seems to be the hardest step. I mean, encoding the width, speed limit, condition, etc. of roads in city X and choosing desirable outcome criteria seems easy compared to building a simulator that will allow me to test potential models with thousands of cars and drivers.Basically, a non-conservative replication system is simple, it's choosing the best offspring that's hard.

• Reply

• Digg
• Bury

Hello,I’ve followed your discussion a bit, and find it interesting. Indeed, we’re currently working on your topic. We aim to create a framework that uses randomized heuristic search algorithms to create programs that could run in Sensor Networks. Therefore, we’re facing some harsh problems (most of them named already). Whatsoever, we could manage to solve some interesting (but not too complicated) Genetic Programming tasks with our project: We were able to grow the Euclidian algorithm for computing the GGD of two natural numbers and some sort of election algorithm genetically. Furthermore, our framework is able to perform Semantic Webservice Compositions, like proposed in <a class="user" href="http://insel.flp.cs.tu-berlin.de/wsc06/.&quot;&gt;http://insel.flp.cs.tu-berlin.de/wsc06/.&lt;/a&gt;The DGPF (our project) is a scalable Java randomized heuristic search algorithm framework, providing distributed Genetic Algorithms and Genetic Programming ability. The aim of the project is to use Genetic Programming to automate code generation for Sensor Networks. Whatsoever, the framework offers powerful search techniques (like distributed GA) that can be used for arbitrary problem spaces. In the current release, we’ve implemented Hill Climbing as complementary search technique to Genetic Algorithms. Both, our Genetic Algorithm implementation and the Hill Climbing implementation come in four distribution forms using the generalized distribution support of the Common Search API:1. LocalThe search runs on a local computer only. This is the suitable if you perform simple searches.2. Peer-To-PeerThe p2p-distribution allows you to let multiple searches run in parallel exchanging results. Additionally, the p2p extension of the Hill Climbing algorithm is fully compatible with the one of the Genetic Algorithms. Therefore, you can integrate Hill Climbing and GA to form a heterogeneous search. The Hill Climbing will then, for example, pick the best solutions from the GA engines, refining them faster (since it does not use a big population). The refined solutions then travel back to the Genetic Algorithms.3. Client-Server / Master-SlaveIf the evaluation of individuals takes especially long, it might be useful to have one central machine that stores the individuals and several others that do the reproduction and evaluation. Thus, you can process complicated individuals in reasonable time.4. Peer-To-Peer - Client-Server HybridThis is the combination of the distribution forms 2 and 3. It allows you to interconnect clusters of Client-Server distributed searches to peer-to-peer networks. Such searches can also co-operate with Hill Climbing and GA searches of the type 2.Maybe it is interesting fact to add here that each search algorithm implemented using the Common Search API is automatically equipped with an auto-adaptive, configurable Tabu Search backend. This backend uses a cache of individuals already evaluated, enforcing the creation of new ones only. The problem space thus will be explored faster and wider. If using one of the distribution schemes involving Client/Server technology, the Tabu Search backend runs on the server side. Only new individuals will travel back to the master (client), reducing network traffic.You can find more information on the DGPF at <a class="user" href="http://dgpf.sourceforge.org&quot;&gt;http://dgpf.sourceforge.org&lt;/a&gt; or <a class="user" href="http://sourceforge.net/projects/dgpf.&quot;&gt;http://sourceforge.net/projects/dgpf.&lt;/a&gt;

• Reply