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

On 12/23/2011 10:07 AM, Dave Abrahams wrote:
On 12.12.2011 06:52, Adrian Michel wrote:
The full documentation is at http://www.amichel.com/de/doc/html but I'd suggest these pages for a first read http://www.amichel.com/de/doc/html/dd/d53/overview.html and http://www.amichel.com/de/doc/html/db/d4e/tutorial.html .
This looks like important and useful stuff to me.
I was wondering what the status of this proposal is. So far several members have expressed interest, but there have been no new posts on this in a while, and I'm not sure what to expect next as far as the boost inclusion acceptance (or rejection) process. Adrian Michel www.tradery.com

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Adrian Michel Sent: Monday, January 09, 2012 3:42 PM To: boost@lists.boost.org Subject: Re: [boost] FW: Proposal for a Differential Evolution C++ library
On 12/23/2011 10:07 AM, Dave Abrahams wrote:
On 12.12.2011 06:52, Adrian Michel wrote:
The full documentation is at http://www.amichel.com/de/doc/html but I'd suggest these pages for a first read http://www.amichel.com/de/doc/html/dd/d53/overview.html and http://www.amichel.com/de/doc/html/db/d4e/tutorial.html .
This looks like important and useful stuff to me.
I was wondering what the status of this proposal is. So far several members have expressed interest, but there have been no new posts on this in a while, and I'm not sure what to expect next as far as the boost inclusion acceptance (or rejection) process.
I, for one, think this looks a very useful library. But few of the Boosters who follow these lists will be expert or even potential users of this 'niche' topic - which is why I think you've not had a deservedly rave response ;-) The documentation looks in a good state. The code looks clean and portable, but finding someone to run on a non-MSVC platforms would be useful - Boost likes to be *seen* to be portable. The folder structure should be 'Boost standard' so that it is possible to use bjam to build and use Boost.Test. (Do not hesitate to ask for help - bjam is the Outer Mongolian of computer languages and using it is a dark art!) You will first need to find a review manager (preferably a Boost contributor), and it will be necessary to have some reviewers too! (Reviewers need not necessarily be currently active Boost followers for a specialist library like this - expertise is the key thing). So you may need to find and drum up support from some potential (or better still, actual) users ? Good luck. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com

On 01/09/2012 09:11 AM, Paul A. Bristow wrote:
-----Original Message-----
I, for one, think this looks a very useful library. [...] So you may need to find and drum up support from some potential (or better still, actual) users ?
I will provide a review if this library gets to review, so far, I've not looked much at this submission.
I think that machine learning is an area where there is enough maturity that implementations in Boost are desirable. A couple of things to consider. It would be desirable that the machine learning topic area be designed a bit more comprehensively than a single library. For example, I should be able to run a GA on the same data as the DE. I would hope that they have the same API. This somewhat implies to me that DE/GA are instances of training algorithms, for which, many are possible. There are many things that go into a ML solution. Data conditioning, model training, model validation, model evaluation. Training in batch modes, instance based, etc. Just to name a couple issues... Then the normal list of library desires...completely generic, optimized for every conceivable configuration (embedded processor, server farm, etc i.e. single process, multi-threaded, mpi, etc) My advice is to be prepared for the big can of worms that this topic could potentially bring up. I think the topic area will be a very hard sell, but would be very useful.

From: Brian Schrom
It would be desirable that the machine learning topic area be designed a bit more comprehensively than a single library. For example, I should be able to run a GA on the same data as the DE. I would hope that they have the same API. This somewhat implies to me that DE/GA are instances of training algorithms, for which, many are possible.
There are many things that go into a ML solution. Data conditioning, model training, model validation, model evaluation. Training in batch modes, instance based, etc. Just to name a couple issues...
I think that numerical optimization is more general than its application to machine learning. While you argue that you'd like to see the library go deep in machine learning I don't see anything wrong with a general purpose numerical optimization library. However, DE is more general than numerical optimization, while the library seems to be an application of DE to numerical optimization. I'm not sure that DE is even one of the best ways to do numerical optimization (I'm pretty sure genetic algorithm is a bad way, so I'm skeptical), and I know I'd like a more general interface to a DE engine than one designed for numerical optimization problems. I'd like to see the library go wide for max applicability rather than deep. Hopefully that will keep it out of all the different cans of worms that could be opened in each application domain. Put numerical optimization and machine learning applications in the example code of the library and submit just the core engine as the library itself. Narrowing the scope of a library submission is usually the path to success. Regards, Luke
participants (4)
-
Adrian Michel
-
Brian Schrom
-
Paul A. Bristow
-
Simonson, Lucanus J