JuliaStats
Single optimization package across time models?
I noticed that GARCH uses the NLopt package, while Kalman uses the Optim package. Would it be possible to use only one optimization package across TimeModels to make the code more uniform, or there are technical reasons which make it necessary to use both NLopt and Optim?
It would be good, I'll look what options Optim package have for constrained optimization.
Great Andrey. I have been using NLopt mostly myself too, but yes, let's have a look at Optim.
My decision to use Optim in Kalman.jl was not for any particular reason...so I'm not attached to it if we want to consolidate the requirements and use NLopt instead.
On Sat, Feb 15, 2014 at 3:51 AM, Theodore Papamarkou < [email protected]> wrote:
Great Andrey. I have been using NLopt mostly myself too, but yes, let's have a look at Optim.
Reply to this email directly or view it on GitHubhttps://github.com/JuliaStats/TimeModels.jl/issues/17#issuecomment-35150616 .
It's great we are all flexible @EIOceanografo and @AndreyKolev. I don't mind which one we choose either, it would be nice to stick with one of these two (whichever it may be). Shall we use NLopt to make Andrey's life easier? I think we will be able to make the transition easily ;) By the way, I fixed a small bug in the Kalman filter, I hope I did it right...!
Correct me if I'm wrong, but I understand NLOpt is a porting of an existing non-linear optimization library while Optim is a pure Julia implementation. If there is functionality in NLOpt not available in Optim it might be worth filing an issue. I'm really not sure how much space is between the two packages. @johnmyleswhite
I agree with your view that Optim is a better option due to being a pure Julia implementation. If we can perform the constraint optimization required for GARCH with Optim, then we can use solely Optim. We have to try and find out if this is possible.
Of course, we should try to use pure julia packages as much as possible, but my main concern is the quality of optimization. Complex time series models simply could not converge if optimization procedure is not good enough (if we will not take in account the misscpecification issues). I'll try to create some benmchmark for garch to see if Optim.jl Box procedure gives the same level of convergence as NLOpt over some lengthy returns series.
That's a good point Andrey. NLopt is a mature library that has been used for longer and by more people. I find it more rational to rely on the NLopt package while writing other packages until Optim grows enough so as to have gravitas comparable to an established library such as NLopt. My take would be to have a release for TimeModels using NLopt and work on a dev branch using Optim until we feel confident that the dev branch can be merged.
I'd generally encourage using NLopt as long as you don't care that your package becomes GPL. If you want a permissive license, you should use Optim.
We should definitely use Optim in the long run. Maybe now that the TimeModels is in its infancy, NLopt is useful for development. In the long run a GPL dependency is not a good idea indeed.