[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078485#comment-13078485
]
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 repository!
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 loops
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: https://issues.apache.org/jira/browse/MATH-621
> 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, bobyqa.zip,
> bobyqaoptimizer0.4.zip, bobyqav0.3.zip
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> During experiments with space flight trajectory optimizations I recently
> observed, that the direct optimization algorithm BOBYQA
> http://plato.asu.edu/ftp/other_software/bobyqa.zip
> 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: http://www.atlassian.com/software/jira
