commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Date Tue, 02 Aug 2011 23:00:27 GMT


Gilles commented on MATH-621:

I certainly also would like the code to be *in* CM. If just for the selfish reason that I've
been working on the conversion for many days now :p. I don't think that _anyone_ wants it
out. However, my view of the CM software library is that it should be a repository of best
practices for scientific computing in Java, and not "just" a toolbox.
This implies IMHO that we try our best that the implementations are coded in a proper OO way...

That said, I'm a bit dismayed that we don't seem to combine our forces to achieve that goal.
I cannot use your new version, and you prefer it to the old one; that is the situation that
I wanted to avoid when I proposed to do a first pass on the code before committing it to the
Please allow me a few more days to get to a "consistent" state (e.g. removing the big work
space). A that point I propose to
# commit your original "straight" translation as provided in your first patch
# commit my current version of that code

Then we can use that as a common base to refactor:
# Replace the "goto"/state machine constructs
# Use matrix operations (from package "linear") whenever possible, in place of the explicit

I don't quite see what seems to bother you with "global" variables versus long argument list.
One of the "problems" of the original (Fortran-like) implementation is that many of the function
arguments are either
* input-output (i.e. they are changed in-place), or
* work space

The former will be more suitably turned into instance variables, and the latter should become
a local variable. I've already started this transformation; it reduces the the length of the
argument lists and make the code clearer namely because one will be able to tell which variables
are input (function arguments) and which are output (instance variable).

The clean, from scratch, implementation is also an option. However, a couple of weeks ago,
I had the impression that no one stepped forward to work on it. That's also why I took the
pedestrian way, having the feeling that we could slowly but surely (thanks to your reference
implementation and unit tests) walk towards the goal of having BOBYQA included in CM before
the 3.0 release (while waiting for the best person for the task would seem to make it unlikely).

Once the 2 commits I talked about above are done, the code will still be far from my ideal
OO but I hope that it will be in a state that will make it more likely that it will evolve
towards that ideal.

How does that sound?

> 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