[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13099061#comment-13099061
]
Nigel Goodwin commented on MATH-621:
------------------------------------
Various responses, then i'm out!
a) you have no idea how grateful I am to you and others for the whole set of
apache commons maths code
b) I use the code for end user applications
c) if it ain't broke, don;t fix it - so my main concern at present is finding
any bugs
d) if you want to redesign Powell's code, using other existing apache code,
good luck! It will not be easy, and will introduce bugs, and will take some
time to settle down. There may be better ways to use your skills and effort.
e) surely the main priority is to create a java BOBYQA which is robust and is
used. Adapting it to conform to some pre-existing or debatable style is surely
secondary?
f) yes, a nice symmetric matrix class with some suitable algorithms would be
nice.
g) I am new to apache, I look around for a lot of mathematical library java
code, there is a lot out there, I use for example JMetal for multi objective
optimisation. I have looked at jama. I have tried out JCuda. Etc etc. What
makes me choose a particular package? Flexibility, simplicity, best of breed
algorithms, easy to understand, easy to extend. Now, coming back to BOBYQA, it
is complex enough that I will probably never attempt to understand or modify
it. So I will just take it as a black box and hope it works. No doubt some
other algorithm will appear in a year or two, and some good person like your
self will also modify it. BOBYQA is complex, and I leave it to the experts, and
will leave well alone unless I have studied it full time for 6 months or more
and know every detail. Not going to happen!
h) I have already moved on and thinking about hybrid quasi newton or radial
basis function/genetic algorithm approaches, but will leave further study to
next year.
i) Oh yes, the one thing I could not find any Java code for was a BesselK
function of second (or third?) order, used to define a Matern function. That
could be a useful extension to apache special functions, more useful work than
'prettifying' a complex algorithm like BOBYQA.
j) Hope you like robust debates! But I fear I am finished here, got to move on
to some more application oriented development.
k) look me up on LinkedIn
> 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,
> BOBYQAOptimizer.java.patch, BOBYQAOptimizer0.4.zip, bobyqa.zip,
> bobyqa_convert.pl, 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
