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@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@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Matt Haberland Assistant Professor BioResource and Agricultural Engineering 08A-3K, Cal Poly