-
Notifications
You must be signed in to change notification settings - Fork 214
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
Levenberg Marquardt Performance Regression on Master #297
Comments
I guess we will have to have a look at those changes once more. Reverting will reintroduce a bug where x could stray out of bounds, so that might not be optimal either. @matthieugomez @bjarthur |
I cannot reproduce your example because I cannot download the package you are using. Are you using bounds when calling levenberg_marquardt? |
ParameterEstimation.jl is waiting to be registered (the PR is in METADATA), but can be cloned if you want to test this (there are a lot of dependencies though since it's pulling in a lot muscle from JuliaDiffEq). I didn't set bounds: I just increased the Note I couldn't find much documentation on using this. It seems LM is left out of the Optim.jl docs (so I went to the code and found it had a docstring). It should really either be documented here, or moved out to LsqFit and documented there. |
That is pretty much why I opened #207, but I guess that's still unresolved. |
@ChrisRackauckas maybe repost @ https://github.com/JuliaOpt/LsqFit.jl/issues ? You can argue that we might want to "backport" any solution you come up with to Optim while we're in the deprecation period. @matthieugomez @bjarthur |
Maybe someone can come up with a more minimal example. The problem I was investigating was parameter esitmation for ODEs. I setup an ODE and generated the data knowing that
a=1.5
:From this we can build a model to optimize:
The Levenburg Marquardt implementation isn't very robust, so it can't stray very far from the true answer and actually get it right:
That gets 1.50 on v0.6.1. However, on master it gets 0.04, i.e. it diverges. When the initial value is instead 1.49, it goes to 0.132. Thus on master it diverges even when starting right next to the true answer.
The only commit in this timeframe seems to be f0f5c18 . I think it should be reverted or investigated more deeply.
The text was updated successfully, but these errors were encountered: