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
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
> 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
>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
10 matches
Mail list logo
