commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dr. Dietmar Wolz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-621) BOBYQA is missing in optimization
Date Wed, 10 Aug 2011 14:48:30 GMT

    [ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082374#comment-13082374
] 

Dr. Dietmar Wolz commented on MATH-621:
---------------------------------------

If you already started writing scripts we should see what they generate. 

I needed several days fixing the indices / removing all newly introduced bugs 
when I moved to 0-based Java arrays. 

My hope is that the indexing problems can be solved by looking into my 0-based 
Java array version.


maybe because I used the C++-port in dlib? 
http://dlib.net/dlib/optimization/optimization_bobyqa.h.html
there are no matrices. 

But I agree, starting with matrices and automatically transform them into 
a Array2DRowRealMatrix seems
a good idea. 


----- Urspr√ľngliche Mail ----
Von: Gilles (JIRA) <jira@apache.org>
An: drdietmarwolz@yahoo.de
Gesendet: Mittwoch, den 10. August 2011, 16:19:27 Uhr
Betreff: [jira] [Commented] (MATH-621) BOBYQA is missing in optimization


    [ 
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082361#comment-13082361
 ] 


Gilles commented on MATH-621:
-----------------------------

Hello Dietmar.

{quote}
Of course I didn't expect
that you restart from scratch, but that we somehow integrate what we have done
so far.
{quote}

But I did not restart from scratch; I used your Java translation and went from 
there!
In fact, it looks like I used the original Fortran because I indeed did 
transform the "ScopedPtr" that were inherently bi-dimensional (i.e. matrices 
like "bmat" and "zmat") into (new auxiliary) "FortranMatrix" objects.
It was only when I checked for the bug in "rescue" that I looked into the 
original Fortran, and discovered that it was using matrices! I still don't 
understand why they were translated into 1-d arrays in your code...

{quote}
Question is now: should we really go to CM matrices in one step, or use 0-based
Arrays as an intermediate step? I could for instance use your code as a basis 
and try
to come up with an 0-based equivalent as an intermediate step. What do you 
think?
{quote}

Going to 0-based loops and replace "FortranArray" and "FortranMatrix" with their 
CM-equivalent ("ArrayRealVector" and "Array2DRowRealMatrix"), which are 0-based, 
can only be done in one step, if I'm not mistaken.

I've started to write a script that would do the translation of everything that 
can be spotted automatically i.e. construct like
{code}
for (int i = 1; i < n; i++)
{code}
and
{code}
zmat.getEntry(2, j)
{code}
and
{code}
FortranArray glag = new FortranArray(n);
{code}
etc.

But there are some contructs that must be changed concomitantly (like some test 
on array bounds in "prelim") and cannot be done automatically. I also suspect 
that some simplification could be done there because of the use of a variable 
containing the "number of evaluations" + 1. Unfortunately, my first attempt was 
not successful :(

So, what I suggest is that
* I finish my (Perl) script; I'll test that it makes all the intended 
replacements (but obviously the resulting code will not pass the tests anymore 
until all the non-trivial replacements have been correctly performed).
* I'll post it here so that you can run it on your working copy
* you could then attempt to perform the rest of the 1-based to 0-based 
conversion.

Once we are left with "ArrayRealVector" and "Array2DRowRealMatrix", we can see 
whether some of the explicit loops can replaced by matrix operation methods from 
CM's "RealMatrix" interface.
After this "low-level clean-up" we can discuss how to introduce the "bounded 
optimization" concept into the CM API (I've already marked the code with "XXX" 
to that purpose).
Concurrently to the preceding point, it would be nice to gradually tackle the 
"goto" problem.

What do you think?



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira


> 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

       

Mime
View raw message