commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dr. Dietmar Wolz (JIRA)" <>
Subject [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Date Tue, 02 Aug 2011 15:03:28 GMT


Dr. Dietmar Wolz commented on MATH-621:

The new version was not mentioned earlier because it didn't exist. I did
that on my vacation and uploaded it at the day I got the tests through.

I suspected you tried something similar but I thought that it would it
make easier for you to locate bugs in your version if you had something
working using arrays for comparison.

Conversion of the state machine is far from trivial, if you want to do
it properly. Problem is that you either define a lot of global variables
or have to transfer a huge number of parameters.

What would the jar-solution mean for the users?
How will a user find the jar,  who will host these kind of black box extensions 
to CM?

Instead of providing a jar you could also provide a dll/shared libraries
together with a JNI interface. It is also a black box - 
but up to six times faster according to my tests. But I agree - performance
is not essentially here because you usually have expensive evaluation functions.

Having the code published could inspire others to work and improve on it.

Gilles commented on MATH-621:

:( It's a pity that you didn't mention this version earlier; I already spent 
quite a few hours replacing the "ScopedPtr" variables. Only a few of them 
remains in my working version: namely, those that are created as offsets in "w" 
before calling "trsbox", "rescue", "altmov" and "update".
Since I also made a few other changes along the way, I don't feel like starting 
all (almost) over again...
Hence, I'll continue with my incremental changes; but, at some point, I could 
use some help to convert the state machine code into proper function calls.

IMO, we should first arrive at a clearer code before worrying about performance 
(the more so that, as you pointed out, this algorithm will probably be put to 
use when function evaluation is expensive, overwhelming the optimizer's code 
running time).

The refactoring from efficient Fortran to (very probably less efficient) Java is 
a big effort but it's indispensable: If it were not to become understandable and 
maintainable, I don't see the point in including it in CM; you could just 
provide the straight translation in a JAR file and people would use it as a 
black box.

This message is automatically generated by JIRA.
For more information on JIRA, see:

> BOBYQA is missing in optimization
> ---------------------------------
>                 Key: MATH-621
>                 URL:
>             Project: Commons Math
>          Issue Type: New Feature
>    Affects Versions: 3.0
>            Reporter: Dr. Dietmar Wolz
>             Fix For: 3.0
>         Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch,,,
>   Original Estimate: 8h
>  Remaining Estimate: 8h
> During experiments with space flight trajectory optimizations I recently
> observed, that the direct optimization algorithm BOBYQA
> from Mike Powell is significantly better than the simple Powell algorithm
> already in commons.math. It uses significantly lower function calls and is
> more reliable for high dimensional problems. You can replace CMA-ES in many
> more application cases by BOBYQA than by the simple Powell optimizer.
> I would like to contribute a Java port of the algorithm.
> I maintained the structure of the original FORTRAN code, so the
> code is fast but not very nice.
> License status: Michael Powell has sent the agreement via snail mail
> - it hasn't arrived yet.
> Progress: The attached patch relative to the trunk contains both the
> optimizer and the related unit tests - which are all green now.  
> Performance:
> Performance difference (number of function evaluations)
> PowellOptimizer / BOBYQA for different test functions (taken from
> the unit test of BOBYQA, dimension=13 for most of the
> tests. 
> Rosen = 9350 / 1283
> MinusElli = 118 / 59
> Elli = 223 / 58
> ElliRotated = 8626 / 1379
> Cigar = 353 / 60
> TwoAxes = 223 / 66
> CigTab = 362 / 60
> Sphere = 223 / 58
> Tablet = 223 / 58
> DiffPow = 421 / 928
> SsDiffPow = 614 / 219
> Ackley = 757 / 97
> Rastrigin = 340 / 64
> The number for DiffPow should be dicussed with Michael Powell,
> I will send him the details. 
> Open Problems:
> Some checkstyle violations because of the original Fortran source:
> - Original method comments were copied - doesn't follow javadoc standard
> - Multiple variable declarations in one line as in the original source
> - Problems related to "goto" conversions:
>   "gotos" not convertible in loops were transated into a finite automata (switch statement)
> 	"no default in switch"
> 	"fall through from previos case in switch"
> 	which usually are bad style make no sense here.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message