[SciPy-dev] GSoC schedule question (letter for my mentors & Matthieu Brucher)

[dmitrey]

hi all,
this is a letter primarily for my mentors & Matthieu Brucher
according to the schedule proposed by my mentors I should work on chapter 2

2. Make existing openopt code usable by adding docstrings,
   unit tests, and documented sample scripts.
   Docstrings must conform to the standard.
   http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
   Tests must conform to the TestingGuidelines
   http://projects.scipy.org/scipy/scipy/wiki/TestingGuidelines
   Make sure ralg and lincher are fully functional, tested, and documented,
   completing as much as possible of your projected work on ralg
   (i.e., constraints to nonsmooth ralg solver (c<0, h=0, lb, ub, A, Aeq),
   as well as their derivatives).  Documentation must be 
   such as to allow other developers to understand and 
   maintain the code, should you cease maintenance.
   Sample scripts should ensure that users have informative
   (and documented!) examples to work with.
   (7 days)

So, one of the main problems for lincher (along with extern QP solver from cvxopt) is: a good line-search minimizer, that takes into account slope angle, is absent (we had discussed the problem some weeks ago in mailing lists).
In scipy.optimize there is only one appropriate func: line_search. However, there are some problems with line_search docstring:

line_search(f, myfprime, xk, pk, gfk, old_fval, old_old_fval, args=(), c1=0.0001, c2=0.90000000000000002, amax=50)
    Find alpha that satisfies strong Wolfe conditions.
    
    Uses the line search algorithm to enforce strong Wolfe conditions
    Wright and Nocedal, 'Numerical Optimization', 1999, pg. 59-60
    
    For the zoom phase it uses an algorithm by
    Outputs: (alpha0, gc, fc)

So, as you see, params are not described; especially I'm interested in old_fval and old_old_fval.
So, there was a letter from NLPy developer about an alternative (link to an article was provided), also, Matthieu proposed using one of his own solvers.
I think the importance of the auxiliary solver is very high and should be done in 1st order. My opinion about next thing to do is using an appropriate solver from Matthieu's package. However, Matthieu's syntax differs too much from openopt one. I think first of all there should be an openopt binding to Matthieu's package, that will allow for oo users to use same syntax:
prob = NLP(...)
r = prob.solve()
I would implement the binding by myself, but I miss well-described API documentation of Matthieu's code. First of all I'm interested
1) what solvers does it contain?
2) how xtol, funtol, contol etc can be passed to the solvers?
then, secondary (it can wait, maybe default parameters would be enough for now)
3) which params can I modify (like type of step (Armijo|Powell|etc), etc) 

BTW ralg is also missing a good line-search optimizer. It requires the one that finds solutions with slope angle > pi/2. But it can wait, it has one quite good and problem with lincher is more actual.

So I think the next GSoC schedule step should be connection of 1-2 Matthieu's solvers (that take into account slope angle, like strong Wolfe conditions do) to native openopt syntax.

Are you agree? 

if yes, my question to Matthieu: can you provide a description of some appropriate solvers from your package? and/or an example of usage?

Regards, D.