Re: [boost] Proposal for a Differential Evolution C++ library

Subject: Re: [boost] Proposal for a Differential Evolution C++ library
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2012-01-11 14:28:36

From: Adrian Michel

>I forwarded Ken Price (one of the DE co-authors) some of the comments I 
>received for his view on things and here's his reply, which hopefully 
>should clarify some of the issues that have been raised:

So I broke down and read the paper.  It is GA with a clever way to choose random mutations by taking the difference between two solutions.  As the algorithm converges there is an implicit anneal in that the differences between solutions tends to get smaller as it converges.  

I was actually thinking of ILP and LP solvers, which is what first comes to mind when I think of numerical optimization, which would be expected to outperform DE for linear problems.  The DE library description needs to be very clear that it is for non-linear numerical optimization.  I'm also curious about how it compares industrial solvers like CPLEX.  That is what I had in mind when I said "good".  It may be DE is one of the best ways to solve a class of problems for which we don't know of a good way.  There is no point arguing about it in subjective terms, however.  Instead, quantifying how big of a problem it can handle in how many compute hours and then providing a reference comparison to other solvers for other classes of problem will put it into context and people will understand easily that it is what it is and be able to tell if it is right for their problem or not.  There are people who may need it and not know it.  There are people who may need something else and not know it.  The documentation should help both types of people.

As far as design goes I would say that you want to split it into generic genetic algorithm engine and a module for performing DE mutations.  The GA and DE-mutation modules would be configured separately and then composed to produce the solution.  That means you need to define an interface between the GA and DE modules, but once you do that then you are able to easily swap out GA engines or apply different mutation modules to achieve different GA algorithms.  I don't think that the mutation module needs to couple to anything to do with the objective function at all.  If someone wants to plug in their HADOOP powered genetic algorithm instead of using the library provided one then they would just use the DE mutations module.  Alternately they could use ASIO to build their own distributed GA module based on the one provided by the library.

Regards,
Luke