Also, new interalg parameter is available: dataHandling. Read http://openopt.org/interalg#Parameters for details.

Another interalg vs BARON test (http://openopt.org/interalg_bench#Test_4) on a constrained prob has been performed, it demonstrates that interalg can be more effective than BARON on problems with huge or absent Lipschitz constant.

]]>min([a, b]) or max((a, 2*b, 100, a-2*b)), where arguments (oovars, oofuns, numbers, numpy arrays etc) should be of size 1.

Thus now you can use min and max in interalg.

Also, you could use min_or_max(oofun_or_oovar), where size of the oofun or oovar > 1, but interalg cannot handle problems with these oofuns/oovars yet.

]]>AFAIK some of you have already ensured that interalg greatly outperforms his competitors, as I have shown in the interalg benchmark

After some changes already committed to subversion repository, interalg now works essentially better and also can get solutions of NLSP (systems of nonlinear equations) no matter are functions from those equations convex, nonconvex, multiextremum etc (or rather quickly ensures that solution doesn't exist).

See the example for details, where interalg get solution while scipy optimize fsolve fails (most likely, due to a local extremum of an equation).

I have some ideas how to essentially speedup solving NLSP by interalg, but I cannot spend much time for OpenOpt development right now, so this and some other future plans for interalg are intended to be implemented later. Maybe, an item from the ones will be implemented till next OO release (2011-June-15). If you'll encounter any bug(s) till the date, I'll try to fix them till the release.

(Updated) Now interalg can get ALL solutions, see here for details

]]>some ideas implemented in the solver interalg (INTERval ALGorithm) that already turn out to be more effective than its competitors in numerical optimization appears to be extremely effective in numerical integration with guaranteed precision.

Here are some examples where interalg works perfectly while scipy.integrate solvers fail to solve the problems and lie about

obtained residual. See http://openopt.org/IP for more details.

Seems like the ideas may be useful for solving (with guaranteed precision) ODE and (maybe) PDE.

Regards, D.

]]>I'm glad to inform you about new release 0.34:

OpenOpt:

* Speedup and many improvements for interalg, now it can work with restricted domains (e.g. log, sqrt on [-1,1])

* Now interalg can obtain all solutions of nonlinear equation (example) or systems of them (example) in the involved box lb_i <= x_i <= ub_i (bounds can be very large), possibly constrained (e.g. sin(x) + cos(y+x) > 0.5).

* Some more bugfixes and improvements

* Python 3 compatibility

FuncDesigner:

* Speedup, many improvements and some bugfixes for interval analysis (and thus interalg)

* Some more bugfixes and improvements

* Python 3 compatibility

SpaceFuncs:

* Changes in FuncDesigner made available using points in constraints, e.g. now you can add constraint "middle of line segment AB is middle of line segment CD" simply as 0.5*(A+B) == 0.5*(C+D) (or mere A+B == C+D)

* Python 3 compatibility

DerApproximator:

* Python 3 compatibility

Backward incompatibilities:

* NLSP renamed to SNLE (system of nonlinear equation)

* FuncDesigner AD on a single oovar returns array, not Python dict, e.g. before: f.D(point, a) = {a:some_value}, now: f.D(point, a) = some_value. Using Python list with single oovar, e.g. f.D(point, [a]), still returns dict {a:some_value}.

* FD oovars() now returns ooarray instead of Python list

As always, you can try our soft online via our sage server, but it often hangs up due to high load.

See also: FuturePlans.

Regards, D.

]]>Some solvers with pure python code (e.g. ralg, interalg, de, qlcp) have passed all tests performed with Python3 .

However, you may encounter some problems during linking Python3 with solvers that contains non-Python code (e.g. C or Fortran).

You may be interested in script **2to3** (search google for more info) that performs automatic translation of Python2 code to Python3. However, it doesn't work with C (or other languages) extensions, so if you have some code connected via Python C API, it will hardly be translated correctly.

It is automatically done for some FD functions (log, sqrt, pow, arcsin, arccos) (like (x>0)(tol = -1e-7), (x>1e-300)(tol = -1e-7) etc in FD versions prior to 0.33; in 0.33 you should pass to openopt prob parameter p.useAttachedConstraints = True; in future useAttachedConstraints probably will have other values (along with True/False) like "userOnly" or "kernelOnly"

]]>I'm glad to inform you about new release 0.33:

OpenOpt:

* cplex has been connected

* New GLP solver interalg with guarantied precision (also can work in inexact mode)

* New solver amsg2p for medium-scaled NLP and NSP

FuncDesigner:

* Essential speedup for automatic differentiation when vector-variables are involved, for both dense and sparse cases

* Solving MINLP become available

* Add uncertainty analysis

* Add interval analysis

* Now you can solve systems of equations with automatic determination is the system linear or nonlinear (subjected to given set of free or fixed variables), see the doc entry for details

* FD Funcs min and max can work on lists of oofuns

* Bugfix for sparse SLE (system of linear equations), that slowed down computation time and demanded more memory

* New oofuns angle, cross

* Using OpenOpt result(oovars) is available, also, start points with oovars() now can be assigned easier

SpaceFuncs:

* Some bugfixes

DerApproximator:

* Adjusted with some changes in FuncDesigner

Backward incompatibilities:

* New OpenOpt parameter p.useAttachedConstraints, is False by default, set it to True to involve them. Maybe this will be reworked till next release, where user- and kernel- attached constraints will be handled separately.

* FD oovars() now returns ooarray instead of Python list

See detailed changelog here

Regards, D.

]]>x = oovars(N)

and several string arguments

x,y, c = oovars('x', 'y', 'speed of sound in material')

FD oovars() can handle single string argument with names separated by spaces:

a, c, c, d = oovars('a b c d')

Of course, number of oovars should exactly match number of words separated by spaces in oovars argument, and names like 'speed of sound in material' cannot be used (use personal assignment by oovar or oovars as above).]]>

I'm glad to inform you about new, 4th OpenOpt Suite module:

**SpaceFuncs** - a tool for 2D, 3D, N-dimensional geometric modeling with possibilities of parametrized calculations, numerical optimization and solving systems of geometrical equations with automatic differentiation (provided by FuncDesigner).

See its home page and documentation for details.

]]>Currently works for inputs a and b of length 3 only.]]>

x = oovars(N)

and solving an OpenOpt prob, instead of gathering x[j] as

x_opt = r([x[j] for i in range(N)])

you can use mere

x_opt = r(x)

However, vectorized x usually are more recommended then using oovars list (review common FuncDesigner programmer mistakes)

]]>