[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dr. Dietmar Wolz updated MATH-621:
----------------------------------
Attachment: bobyqaoptimizer0.4.zip
The attached new version contains three variants of BOBYQA implementing the
MultivariateRealOptimizer together with their associated unit tests:
BOBYQAOptimizerOld - essentially the previous version 0.3 with minor adaptions
in the unit tests added for comparison.
BOBYQAOptimizer - the actual version I use myself - all "pointers" are replaced
by Java arrays. This version is much easier to read and faster than the old
one. Nevertheless the "finite state machine logic" realized by the original
code using gotos is still there - in Java realized using switch/case statements.
BOBYQAOptimizerC - a version showing how MultivariateRealOptimizer can be
implemented using the C-port of BOBYQA from the dlib library. The C++-code
doing the mapping from Java to C++ to Java via JNI is also included.
Some remarks:
- all three versions are semantically equivalent - at least from the point of
the actual unit test coverage.
- the new Java version is about 30% faster than the old one - array access is
cheaper than method calls simulating pointer arithmetic.
- I observed a significant change of behaviour when statements like
a = a+(b...) are replaced by a += (b...). Subtle accuracy differences add up
during the optimization process.
- The C version was tested both on Mac (Snow Leopard) and Windows7,
both for 32 and 64-bit Java. For 64bit the Microsoft C++-compiler produced
correct
results only if optimization is switched off completely, on the Mac the
gnu compiler works correctly using -O3.
- On the Mac (a Macbook pro with a new sandy bridge processor) the C-version
performs the unit tests three times faster than the (new) Java version.
The difference on Win7 is much smaller, since I couldn't use compiler
optimization
there yet. The performance difference is not significant for my own application
of the algo (space flight trajectory optimization) because of the high cost for
the eval function. But this is perhaps not true for all other applications.
So if we want to include BOBYQA in commons.math in my opinion we shouldn't
neglect performance issues generally. Even a direct port of the code has a
significant
performance disadvantage, any refactoring should try to avoid adding too much
additional performance bottlenecks.
> 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
