-
Notifications
You must be signed in to change notification settings - Fork 2.1k
fixes to find_MAP #2468
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fixes to find_MAP #2468
Conversation
- float32 support - different arg, method="L-BFGS-B" instead of fmin=optimize.fmin_l_bfgs_b - allow keyboard interrupt, save current value - returns untransformed and transformed variables - removes monitor, adds tqdm progress bar
|
||
r = fmin(logp_o, bij.map(start), fprime=grad_logp_o, callback=callback, *args, **kwargs) | ||
if method in ["CG", "BFGS", "Newton-CG", "L-BFGS-B", "TNC", | ||
"SLSQP", "dogleg", "trust-ncg"]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would mean if I provide a custom method I can not use the gradient?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh good catch, it would be nice to be able to provide a custom method. I'll try and fix that.
@bwengals I think using |
@aseyboldt I actually tried that first, but got a bit tripped up. I wasn't sure about using the bijection stuff to go from a |
Yes. You could use something like:
Then move between arrays and points through At the moment you can't disable gradient computations, but this would be easy to add. |
List of variables to set to MAP point (Defaults to all continuous). | ||
fmin : function | ||
Optimization algorithm (Defaults to `scipy.optimize.fmin_bfgs` unless | ||
method : string or callable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it really that much more convenient to allow strings here? In particular, is this minor convenience more important than preserving the API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. Some benefits I can think of is it matches up a bit better with sample
and fit
, which specify the method with strings. Also, minimize
can take a homebrew optimizer, which may be nice. It also gives a consistent interface for all scipys optimizers. The different fmin_*` functions are sometimes a little bit different. Draw back is breaking peoples code...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way SGTM, just wanted to bring up the API stability concern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah I'm not sure how folks feel about it
Fixing the lack of transformed values is a pretty important feature, so that will be good to have. |
FWIW, passing the transformed RVs is sufficiently useful that I've started using this branch in my own work. |
@kyleabeauchamp Ah sorry for my slowness finishing this up! Been buried in gp land... planning on being back on it tomorrow |
See my PR into your fork: bwengals#1 |
Pull in upstream/master and fix conflicts
Do people have further thoughts on what to do about this PR? Do we want to continue with the deprecation of fmin? I ask because the other components of this PR (e.g., MAP estimates of transformed + untransformed variables) are features that we and others are very interested in. |
In order to sidestep the discussion on the |
closing in favor of #2539 |
For issue #2466.
method="L-BFGS-B"
instead offmin=optimize.fmin_l_bfgs_b