search

JuliaStats / TimeModels.jl

Modeling time series in Julia
Other
57 stars 28 forks source link

Single optimization package across time models? #17

Open papamarkou opened 10 years ago

papamarkou commented 10 years ago

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?

AndreyKolev commented 10 years ago

It would be good, I'll look what options Optim package have for constrained optimization.

papamarkou commented 10 years ago

Great Andrey. I have been using NLopt mostly myself too, but yes, let's have a look at Optim.

ElOceanografo commented 10 years ago

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 < notifications@github.com> 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 .

papamarkou commented 10 years ago

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...!

milktrader commented 10 years ago

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

papamarkou commented 10 years ago

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.

AndreyKolev commented 10 years ago

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.

papamarkou commented 10 years ago

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.

johnmyleswhite commented 10 years ago

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.

papamarkou commented 10 years ago

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.