ENH minimize, minimize_scalar: Add support for user-provided methods #3369
Conversation
| @@ -328,11 +394,11 @@ def minimize(fun, x0, args=(), method=None, jac=None, hess=None, | |||
| warn('Method %s does not use gradient information (jac).' % method, | |||
| RuntimeWarning) | |||
| # - hess | |||
| if meth not in ('newton-cg', 'dogleg', 'trust-ncg') and hess is not None: | |||
| if meth not in ('newton-cg', 'dogleg', 'trust-ncg', '_custom') and hess is not None: | |||
There was a problem hiding this comment.
What's the point of this addition? A custom method could use hess or hessp. If something needs to be checked I'd say it should be in the method function itself.
There was a problem hiding this comment.
On Sun, Feb 23, 2014 at 12:00:38PM -0800, Denis Laxalde wrote:
@@ -328,11 +394,11 @@ def minimize(fun, x0, args=(), method=None, jac=None, hess=None,
# - hess
- if meth not in ('newton-cg', 'dogleg', 'trust-ncg') and hess is not None:
- if meth not in ('newton-cg', 'dogleg', 'trust-ncg', '_custom') and hess is not None:
What's the point of this addition? A custom method could use
hessorhessp. If something needs to be checked I'd say it should be in the method function itself.
Exactly - a custom method could use hess, therefore it is
inappropriate to print a warning when hess is passed that asserts that
the method does not use Hessian. I agree with your second sentence,
that is why I'm exempting _custom from these checks.
|
Thank you both for reviewing the patch! I have updated the pull request with a revised commit, I believe (and hope) I have addressed all your comments (and I changed nothing else). |
|
Petr Baudis a écrit :
Looks good to me, except for the example in the docstring which I still |
|
my 2cts: maybe a tutorial is a better home for this example |
|
Tutorial makes sense. @pasky do you want to move that to |
|
All right, I have pushed an update that just moves the example code to a tutorial (with tiny introduction) and adds a reference to the tutorial to the docstring. |
|
Just one more thing @pasky. Do you find it convenient to unpack the |
|
I had two motivations to keep unpacking **options: (i) Consistency. This seems to me to be a worthy goal by itself to me, (ii) Convenience. If I accept options, I can simply specify them in |
|
This update just adds a description of the change to the release notes. |
| bestx = testx | ||
| improved = True | ||
| if callback is not None: | ||
| callback(x0) |
There was a problem hiding this comment.
TravisCI pyflakes run flagged that x0 is not defined here.
|
Other TravisCI failures are unrelated. |
|
@dlax are you OK with the reply to your |
|
Thanks, fixed the callback() parameter and added a note about version. (I think versionadded tag is not appropriate as that has to be a separate paragraph?) |
|
Indeed, the way you added the version info looks good. |
|
Ralf Gommers a écrit :
Yes, it's fine. Will merge. |
ENH minimize, minimize_scalar: Add support for user-provided methods
I'm using the excellent scipy.optimize infrastructure for research, experiments and benchmarking of some custom local minimization strategies. However, without this simple change, I have no easy way to plug my minimizer to basinhopping to overload it for global minimization as well; first I added a direct override possibility in PR #3321, but it has been pointed out that a more generic mechanism that could cover other cases would be nicer. A global registry of custom method names has been another idea, implemented in PR #3333 and it has its merits, but it has been deemed that overally a simpler and nicer way is simply passing a callable as the method parameter, instead of a string.
Therefore, this change does just that, checking if method is a callable instead of a string and in that case just going ahead and calling it - both in minimize and minimize_scalar of scipy.optimize. It now also includes examples in the documentation and test suite checks.