scale parameter for lpSolve

I have committed scale parameter (bool flag) handling for lpSolve.

It should be used as

p.solve('lpSolve', scale = 1)
or
p.solve('lpSolve', scale = True)

bugfix for constrained NLSP graphic output

I have committed the bugfix mentioned in OO GSoC timeline.
Here's graphic output for a little bit modified /examples/nlsp_constrained.py.

bugfix for ralg A, Aeq constraints handling

I have committed bugfix for ralg A, Aeq constraints handling.
Unfortunately, the bug is present in 0.18, when I add Point class.

connecting algencan 2.x beta

Some weeks ago I had downloaded and compiled algencan 2.0 beta (version from March 25). Now new version is available: 2.0.1 beta, but currently I fail to compile both these versions (I guess because of some KUBUNTU updates). Fortunately, I can use those old compiled files from 2.0 beta.

So I have provided OO-algencan 2.0 beta connection (I guess it should work with 2.0.1 as well).

On the other hand, v 1.0 works better than 2.0beta (at least for those examples I have examined). Mb v. 2.0.1beta or v. 2 release will work better?

also, pay attention to the issues:

you should remove old algencan files (first of all pywrapper.so that is situated somewhere on your PYTHONPATH). Mb I could use some tricks to allow both ALGENCAN (i.e. 1.0) and algencan (i.e. v 2.x) to be available in OO, but it requires some more efforts, and I don't see much sense because in future ALGENCAN support will be ceased.

provide algencan with either bigger gradtol (1e-1...1e-5 instead of default 1e-6) or other stop criteria like maxTime, maxCPUTime, maxIter, maxFunEvals

you can encountered text output "PYTHON INTERFACE ERROR: in evalg, PyEval_CallFunction returned NULL" - this one is due to stop triggering (maxTime, maxCPUTime etc, via Python exception) of artificially binded OO iterfcn, because currently algencan has no native one (here's the thread with my proposition to create the one)

bugfix for ipopt linear constraints handling

I have committed bugfix for ipopt linear constraints handling Ax<=b, Aeq x = beq.
I just forgot to implement the one because ipopt API has only x_L <= x <= x_U and g_L <= g(x) <= g_U constraints.

OpenOpt 0.18

Hi all,
I'm glad to inform you about new OpenOpt release: v 0.18.

Changes since previous release 0.17 (March 15, 2008):

• connection to glpk MILP solver (requires cvxopt v >= 1.0)


• connection to NLP solver IPOPT (requires pyipopt installation, that is currently available for Linux only)


• major changes for NLP/NSP solver ralg


• splitting non-linear constraints can benefit for some solvers


• unified text output for NLP solvers


• handling of maximization problems (via p.goal = 'max' or 'maximum')


• some bugfixes, lots of code cleanup

Regards, Dmitrey.

major changes for ralg

I have committed some major changes for ralg (+ some more code for prob.point, to simplify my further OO development).

Since I have been busy with connecting ipopt and these ralg changes, patterns are intended to be implemented in next OO release.

Below is output of OO v0.17 ralg vs current ralg implementation (made by /examples/nlp_bench2.py for N=100). Usually OO v0.17 ralg consumes about 5-10% objFunc and 3-5% nonlinear constraints evaluations greater.