Include brute as method option

[nmearl]

Is it possible to include scipy's brute method as an option? I know this may be rather specific -- I need to do a comparative analysis -- but I was hoping if its not too difficult it can be done. I'm looking at the Minimizer function now, but I don't want to muck around in there if it's something that could be easily done by someone who knows the code better.

[newville]

On Fri, Dec 6, 2013 at 12:04 PM, nmearl notifications@github.com wrote:

Is it possible to include scipy's brute method as an option? I know this
may be rather specific -- I need to do a comparative analysis -- but I was
hoping if its not too difficult it can be done. I'm looking at the
Minimizer function now, but I don't want to muck around in there if it's
something that could be easily done by someone who knows the code better.

I think it's a good idea to add "brute", but I haven't looked into this
myself. One obvious question is whether the ranges and number of samples
should be attributes of the Parameters -- that seems preferable to me, but
is probably a bit more work.

Anyway, it would be a great addition, and a good project. I'd encourage
you to look into trying this.

--Matt Newville

[slhck]

I was wondering whether anyone has looked into this again or has some code to start with?
I'm afraid my own experience with Python as a whole and lmfit (or SciPy) in particular is very limited.

[andyfaff]

My guess is that you'd be better off with differential_evolution.

[slhck]

I'll give that a shot. Thanks, @andyfaff

[newville]

@slhck @andyfaff It's very interesting and timely for me that you bring this up now! In fact, I was having a conversation in my lab yesterday about setting up an auto-focus-like system, and the conversation turned to doing a brute-force / grid search followed by a least-squares/steepest-descent approach. But the objective function would be moving motors and measuring an image from a CCD camera, so we need to be able to impose limits on the variables (motor positions). So, using lmfit and starting with a brute force grid and then "polishing" with least-squares would be great for this.

The scipy.optimize.brute is not very long and devotes much of its space to the "polishing step", which we don't really need since we can just replace the fitting method in lmfit. So, I would suggest that we add a brute() method using Parameters and their min/max values as the bounds ourselves. Using numpy mgrid and vectorize would make the whole thing pretty easy, as scipy.optimize.brute shows. One could either have a single Nmesh value, implying a uniform number of points for each variable Parameter, Or perhaps allow each Parameter to have a "ngrid" attribute? It would also be nice to put the entire set of results into the MinimizerResult, so that surface-plots of parameter pairs could be easily visualized.

FWIW, differential evolution seems to me a useful but different thing. A brute-force mesh-search has the appeal of having easily predicted number of evaluations and mesh size, making it appropriate for "broad surveys of parameter space" and for giving an idea of how complicated the parameter landscape is.

Anyway, I think this should be done. I would encourage you to try doing this if you're interested, and would be willing to help.

[reneeotten]

@newville this issue can be closed: it was added in commit 22b40fd.

[newville]

@reneeotten Thanks!