Tentative roadmap

[johnmyleswhite]

• API cleanup
  • Formal API For interacting with optimization results by merging a successor to [WIP] Official API for interacting with optimization results objects #87
  • Replace method symbols with abstract types to exploit type dispatch and simplify exposing custom keyword arguments for different methods
• Documentation
  • Document a formal API
  • Provide examples of basic problems one might want to solve
• Benchmarks
  • For every problem we test against, we should log the number of iterations, the number of function calls and the number of gradient calls. Shrinking any of these numbers is the best way to improve perf.

[pkofod]

Should API discussions happen at #87 ?

[johnmyleswhite]

Probably, but I'm not worried if discussion is split a little bit.

[pkofod]

Constrained optimization should probably be added as well, even if @timholy might not have the time right now (or someone else).

[Evizero]

I'll probably have some time in about a week or two to work on some aspects of this. If no one else is already doing it, that is.

Replace method symbols with abstract types to exploit type dispatch and simplify exposing custom keyword arguments for different methods

I am assuming you mean adding a positional argument to optimize that defines the algorithm to use, right? (e.g. something like BFGS()) A lot of the verbose code in optimize.jl could be avoided that way. Plus it would be easier to extend the functionality.

For every problem we test against, we should log the number of iterations, the number of function calls and the number of gradient calls

I do something along the lines for KSVM.jl to compare the results of my implementation against scikit learn that I stored in csv files. Does this go in the direction you're thinking of?

---

One reason I would like to work on this is because I would kinda like to sneak-in early stopping to the callback functions. Does this at all fit into your design goals?

[tkelman]

• think about removing nnls if https://github.com/ahwillia/NonNegLeastSquares.jl is strictly better?

[davidanthoff]

Not sure this is within the scope for anything near term, but long term it would be really neat if the algorithms in Optim were exposed as MathProgBase solvers, and if the user facing API in Optim would just be a user friendly layer over MathProgBase.

[mlubin]

I wouldn't want to impose the MPB interface, it's not necessarily the most natural for unconstrained or box-constrained problems (that should improve with @timholy's proposal at JuliaOpt/MathProgBase.jl#87). In any case writing an MPB wrapper for an Optim algorithm shouldn't take more than 20 lines of code.

[pkofod]

Does anyone have any good examples of maintaining a good/robust/automated perf log/benchmark history? I think that right now, we're kind of in the dark wrt. the evolution of the mentioned perf measures throughout the commit history.

[pkofod]

This discussion is superseded by #326 and/or solved.