How to pass "args" to Minimizer.brute?

[aeiou6630]

Just a quick question. While scipy.optimize.brute can take additional arguments via args = ... , I found Minimizer.brute doesn't accept any args. Is there a way to add it? Thanks!

[newville]

@aeiou6630 looks like we don't support that.

[aeiou6630]

Got it. I tried to modify the code in minimizer, but didn't succeed, yet afterwards I was able to use global variables to bypass this issue. Thanks for your reply.

[newville]

@aeiou6630 well, we might want to fix this ;)

[aeiou6630]

Thanks guys. Though I guess you probably have well understood it, I'll provide a minimal example:

from scipy.optimize import brute

def func(x, x0):
return (x-x0)**2

x0 = 5
ranges = [slice(0,10,1)]
args = tuple([x0])
result = brute(func, ranges, args = args)

, where x0 is the thing I think Minimizer.brute cannot handle at the moment.

[reneeotten]

Please look at the example provided in the gallery.

For example, there we created a Minimizer and provide parameters:

fitter = Minimizer(fcn2min, params, fcn_args=(x, data))
result_brute = fitter.minimize(method='brute', Ns=25, keep=25)

and checking the call_kws that are given in the end to scipy.optimize.brute we see:

{'full_output': 1, 'finish': None, 'disp': False, 'Ns': 25, 'workers': 1}

exactly as it should be.

So again, I am sorry if I am not understanding it correctly... and as I asked earlier provide an example that uses lmfit to show what you want to do and what doesn't work.

[newville]

@reneeotten Yes, that is the call_kws, but this does not include an argument called args that scipy.optimize.brute supports. And there is no way to pass that to lmfit.Minimizer.brute or into lmfit.Minimizer and then have it sent to scipy.optimize.brute.

[reneeotten]

@newville I don't think it has to include an "args" argument as that is supposed to provide things/parameters to calculate the residual function. That is what "fnc_args" is intended for. The parameter "Ns" in my example was changed from its default and does get passed correctly "scipy.optimize.brute".

A few other things that are listed in "brute_kws" (i.e., 'full_output', 'finish', 'disp') can indeed not be changed as is documented in the docstring, but that's what I decided on when adding this method. There should be no compelling reason for the end-user to change those.

[newville]

@reneeotten Yes, I agree that one could pass fcn_args to lmfit.minimize.

It is not always clear how or when to decide which arguments of the scipy.optimize routines we support.
If someone is familiar with scipy.optimize.brute and wants to use the args argument, should we allow that?
Perhaps that should set self.userargs, or maybe it is better to raise a Warning pointing to fcn_args to better ensure uniformity in our API (uniformity in scipy.optimize appears hopeless to me). It seems like we currently ignore the argument, which is probably not ideal.

[aeiou6630]

Oh, I didn't notice the fcn_args option when creating a Minimizer object. That indeed solves it. Thanks!

[reneeotten]

@newville I see your point and realize now that the brute method is the only one that doesn't have a **kws`` kitchen-sink option for the user to supply whatever they want... I still think that would be okay here as it is documented which options cannot be changed (and I don't see a reason for someone to do that). In most examples (including the ones for brute) we use the fcn_argsargument to theMinimizerclass to supply the required variable for the residual function instead of using theargsoption that pretty much allscipy.optimize` solvers have.

To me that would be a better way of doing it and I'd be in favor of removing the **kws option from all solvers we have in lmfit and only have the named arguments to the function specifically listed in the function call. However, I realize that this will not fly well as it breaks backwards-compatibility for a not-good-enough reason ;) So if you really prefer I suppose we could add to the brute method as well; the only issue is then that we would probably need to remove the "named" arguments as otherwise there is a possibility to provide the same argument twice. Doing so now would of course break backwards compatibility for the brute method; anyway, I don't really care - so if you have a strong opinion let me know...

[newville]

@reneeotten perhaps we should give a warning if args is used with brute, suggesting fcn_args as the alternative?

We should not feel obligated to follow the scipy.optimize API, or really even use their code. Like, it would be perfectly reasonable to just use our own implementation of brute (we've done others in the past). I'm not advocating for that: we can use their implementations but I think it is OK to say we use them as they suit our needs. We don't need the args argument of brute. But maybe we could warn when the user passes in keywords that we know we are going to ignore?