[SciPy-Dev] Using global minimizer methods from `optimize.minimize` function

[Matt Haberland]

Just wanted to mention that I'm in favor of adding the option of accessing
`differential_evolution` via minimize, and my comments are at the PR
<https://github.com/scipy/scipy/pull/10778>.

On Wed, Apr 29, 2020 at 7:43 PM Andrew Nelson <andyfaff at gmail.com> wrote:

> I  sort of think these pros are overstated.  The dispatching of what
>> function to call does not seem that difficult to do (either in `minimize`
>> or in user code).  The benefit of having that dispatch of function name
>> happen within `minimize` is small.  Normalizing the APIs so that the
>> options sent to the underlying methods is harder and also more valuable.
>> That is, in order for the dispatching to really be valuable, it has to
>> unite and offer a translation layer to the calls to the underlying
>> functions.
>>
>
> A recent issue (https://github.com/scipy/scipy/issues/11956) highlighted
> this issue. Here the author wanted to use a constraints dict with
> differential_evolution, similar to that can be provided to `minimize` (de
> uses the new style `NonLinearConstraint`). If  differential_evolution was a
> `minimize` method that translation would be done automatically. The same
> argument applies for translation of new style and old style bounds. Is that
> what you mean by normalising the API?
>
>
>> The global solvers have many different optional arguments with little
>> overlap in name or meaning.  Like, 'popsize' is only used by
>> 'differential_evolution'. The plan would have to be to silently ignore
>> keyword arguments for concepts not used by the currently used method.  I'm
>> not sure that helps achieve clarity and simplicity.  To use these methods,
>> the user has to read the docs for the actual solver to get the many
>> optional arguments set anyway.  At that point, they can just as easily
>> change the name of the function.
>>
>
> There are many optional arguments for each of the methods as-is. The most
> common are jac and hess which are used across some, but not all methods.
> L-BFGS-B has `iprint`, `gtol`, `maxls` which aren't used by most other
> methods. Over supply/non-supply (i.e. concepts not used by specified
> method) of these keywords is already handled by minimize, and by the
> minimizers themselves (via `_check_unknown_options`). Your line of
> reasoning runs counter to the design of the `minimize` function, and would
> suggest a return to the old-style minimize functions: fmin, fmin_l_bfgs_b,
> etc. (The documentation states "The functions below are not recommended
> for use in new scripts; all of these methods are accessible via a newer,
> more consistent interfaces, provided by the interfaces above.")
>
> But, I think there is another concern that may not have been expressed
>> yet. `x0` is a required, positional argument for `minimize()`, as an array
>> of initial parameter values.   Most of the global optimizers in
>> scipy.optimize do not use `x0`.  Instead, they require bounds and explore
>> the range of values between those bounds.   Would `x0` be required AND
>> ignored for these global optimizers?
>>
>
> The call signature for required positional arguments for `minimize` is
> different to the global optimizers. Being able to call the global
> minimizers via `minimize` would alleviate that. As you say the global
> minimizers do explore within bounds, and don't use an `x0`. The PR (as it
> currently exists) would still require `x0`, and it would be ignored.
> It would be possible to change that behaviour for
> `differential_evolution`, but would require the modification of the code to
> accept an `x0` keyword.
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>


-- 
Matt Haberland
Assistant Professor
BioResource and Agricultural Engineering
08A-3K, Cal Poly
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20200429/16162ac8/attachment-0001.html>