>If nobody is able to work on "BOBYQAOptimizer" so as to make it a
>maintainable and documented code, I request that it be removed from the next
>major release (4.0).
No objections from my side. BOBYQA was again heavily used at
https://issfd.jpl.nasa.gov/home/GTOC6 (10th place this time), but
Will have a look when Gilles finished the change next week.
Dietmar
-Ursprüngliche Nachricht-
Von: Gilles Sadowski [mailto:gil...@harfang.homelinux.org]
Gesendet: Montag, 7. November 2011 15:22
An: dev@commons.apache.org
Betreff: Re: [math] CMA-ES input sigma
> [...]
> >
> > P.S. Pleas
+1
also valid for CMA-ES
>
>This would be great too. Maybe I could get some contacts with Serge
>Gratton. Cerfacs is in Toulouse and I know for sure many people who have
>direct contact with him. I even think he was present at the same small
>seminar we attended together when you and Nikolaus presented your work
>on CMA-E
Hi Luc, Gilles,
obviously I tend more in Lucs direction, although I understand Gilles
point of view. Specially since he is volunteering to invest time
to produce something maintainable. I will be on vacation from next
tuesday, so you can be sure there will be no overlapping work.
For sure I also tr
Indeed it was not easy to get the thing converted. I will apply all the
tests
I already wrote for CMA-ES (they could be refactored out in a separate
class later). The last two bugs I detected resulted only in
a slight performance decrease and were only detected by debugging both
programs in paralle
Here is the letter from the Autor which I received yesterday.
There seems to be no problem regarding a signed agreement.
I will send him our conversation, so you can get directly in contact.
"Dear Dr Wolz,
Many thanks for your e-mail. I was delighted to hear of your interest in
BOBYQA and
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 significant
> In fact, I've only ever seen "testMaximize" and (less often) "testRosen"
> fail. So, for the time being, I'd add "@Retry" to those only.
+1 for adding @Retry to the two tests occasionally failing
-
To unsubscribe, e-mail: de
Nikolaus Hansen, Luc and me discussed this issue in Toulouse.
We have two options to handle this kind of failure in tests of stochastic
optimization algorithms:
1) fixed random seed - but this reduces the value of the test
2) Using the RetryRunner - preferred solution
@Retry(3) should be suffici
>However, can we slow down on the new features? (Am I saying this? ;-)) [We
previously agreed that the main algorithm code should be put in place before
>any other bells and whistles.]
We didn't discuss when a possible enhancement of
MultiStartMultivariateRealOptimizer
will be implemented, just w
>Should we simply allow user to register an instance of some optimizer
reconfigurator interface in the constructor ? Something like:
>
> public MultiStartDifferentiableMultivariateVectorialOptimizer(
> DifferentiableMultivariateVectorialOptimizer optimizer,
> int starts,
>
There is another topic worth mentioning:
Multi-start using MultiStartMultivariateRealOptimizer.
In http://www.lri.fr/~hansen/cec2005.html an algo
called G-CMA-ES performed very well:
A CMA evolution strategy restarted with increasing population size.
Is there a general need beside CMA-ES to modi
>that depends on math 2.1. Orekit itself (or whatever other immediate
>dependency) may not have cut a release changing its internal use to 3.0. At
Is this realistic? I would expect quite early an Orekit version supporting CM
3.0.
May be not a release but the actual Orekit trunk. So for your o
>The name change is not for maintaining several versions in parallel. It
>is to allow projects to have parts depending on the old (unmaintained)
>version and new (maintained) version to compile and let them go back in
>sync progressively. It is exactly the same process than the change in
>2.2 for
>> Yes, we can start with a bare implementation and add the bells and
>> whistles afterwards. In this case, they could also be integrated to the
>> other optimization algorithms if something general enough is found.
>+1
As soon as Nikolaus review is finished I will prepare the patch. Unit tests
>>
>> And an iterative algorithm that implements "HandlerSetter" will call
>> "update" after each iteration.
>Yes, this is the way user can monitor what he wants. Perhaps with a few
>set of more specialized handlers, the signature of the update method
>could be adapted for the algorithm type (i
>There is something loosely similar to what you need in the ODE packages.
>This kind of algorithms also need some information to be provided back to
>users during the algorithm run. For ODE solvers, it is at the end of each
>integration step.
>We have set this with a StepHandler interface. If t
>I really don't think that a general progress listener framework implies this
>clutter and for long running algorithms is a very nice thing. CM does not
>actually have all that many long running algorithms.
>On the other hand, the proposed interface is not a general progress listener
>and is n
>The problem is that we would again be re-inventing some wheel which IMHO
doesn't belong to a low-level math library such as CM.
>A basic logging interface already exists: It's "slf4j".
slf4j and the interface I had in mind are completely different things. slf4j
is a generic logging interface mea
>Did you use the "MATH_2_X" or the "trunk" repository?
I think "MATH_2_X", but will test with trunk. I think the patch should
be against trunk?
>> modifiable. Should we create an additional interface extending
>> MultivariateRealOptimizer which covers this aspect?
>No.
>All the parameters must
A new Jira issue was recently created
https://issues.apache.org/jira/browse/MATH-442
regarding the contribution of a new optimization algorithm CMA-ES.
Recently I implemented the optimization algorithm CMA-ES based on
org.apache.commons.math.linear and used it for
22 matches
Mail list logo