# [SciPy-dev] Proposal for more generic optimizers (posted before on scipy-user)

dmitrey openopt@ukr....
Thu Mar 22 08:33:04 CDT 2007

```Hallo Matthieu Brucher, Alan Isaac and other developers,
this is a last-year postgraduate from instityte of cybernetics, Ukraine
I'm interested in the way you intend to continue optimization routines
development in Python, & I'm observing the thread in forum.
Despite I'm member of all 3 mailing lists referred to scipy/numpy, my
messages somehow return "waiting for moderator approvement" & nothing is
published. That's why I decided to add your emails for more safety in
So I have 3 years experience of optimization in MATLAB, and some
experience with TOMLAB (tomopt.com).
I wrote toolbox "OpenOpt" which can run both MATLAB & Octave

there are 6 solvers currently: 2 nonsmooth local (from our deparment) &
4 global (connected from other GPL sourses). There is also nonSmoothSole
- fsolve equivalent for nonsmooth funcs (no guarantie for non-convex
funcs), and example of comparison is included.
The key feature is TOMLAB-like interface, it's like that:
prob = ooAssign(objFun, x0, .....<optional params>)
r = ooRun(prob, solver)
in TOMLAB you should write strict manner, like
prob = nlpAssign(objFun, x0, [],[],[],A,b,Aeq,beq,[],[],[], [],[],f0,[],...)
so I decided to replace it by string assignment
prob = nlpAssign(objFun, x0, 'A', A, 'beq', beq, 'Aeq', Aeq)
or
prob = nlpAssign(objFun, x0, 'A=[1 2 3]; b=2; TolFun=1e-5; TolCon=1e-4;
doPlot=1') etc
then params may be assigned directly:
prob.parallel.df=1;%use parallel calculation of numerical (sub)gradient
via MATLAB dfeval()
prob.doPlot= false;
prob.fPattern = ...
prob.cPattern = ... %patterns of dependences i_th constraint by x(j)
prob.hPattern = ...

prob.check.dc=1;

etc

So some time later I encounted things that don't allow effective further
development (first of all passing by copy, not reference), & now I'm
rewriting its to Pyhton (about 20-25% is done for now).
I've got some experience and things in Python ver will be organiezed in
a better way.
for example
prob = NLP(myObjFun, x0, TolFun=1e-5, TolCon=1e-4, TolGrad=1e-6,
TolX=1e-4, MaxIter=1e4, MaxFunEvals=1e5, MaxTime=1e8, MaxCPUTime=1e8,
IterPrint=1etc);
# or prob = LP(...), prob = NSP(...) - nonSmoothProblem, prob = QP(...) etc
prob.run() # or maybe r = prob.run()
I intend to connect some unconstrained solvers from scipy.optimize.
All people in my department are opensourse followers; we have much
optimization-related software (most is for nonsmooth funcs & network
problems, we research them from 1965), but almost all is Fortran-written.
I intend to call for GSoC support, but the only one scipy-related person
I found in http://wiki.python.org/moin/SummerOfCode/Mentors is Jarrod
Millman <http://wiki.python.org/moin/JarrodMillman>
And as far as I understood from conversation with some persons from PSF,
this year in GSoC they are interested first of all in Python core, so
chances for getting support are very low. However, if you can help me in
There are also some chances to achieve direct google support, but last
year only 15 students have sucseeded.
But I will continue my work in anyway.
WBR, Dmitrey.

Matthieu Brucher пишет:
> Hi,
>
> I didn't have the time to make the changes Alan proposed, but I would
> The goal of my proposal is to have something better than MatLab
> Optimization Toolbox, at least for the simplest optimization, domain
> where Matlab does not use the litterature - for instance the
> conjugate-gradient method seems to not use the Wolfe conditions for
> convergence... -.
> And the structure for an optimizer is thought so as to be more
> modular, so implementing a new "optimizer" does not imply writting
> everything from scratch. Everything cannot be thought in advance, but
> some can.
>
> Matthieu
> ------------------------------------------------------------------------
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev@scipy.org
> http://projects.scipy.org/mailman/listinfo/scipy-dev
>

```