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
Le 26/11/2010 11:58, Dr. Dietmar Wolz a écrit :
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
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,
Le 26/11/2010 13:34, Dr. Dietmar Wolz a écrit :
Should we simply allow user to register an instance of some optimizer
reconfigurator interface in the constructor ? Something like:
public MultiStartDifferentiableMultivariateVectorialOptimizer(
Hello.
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,
[...]
Question is how reconfigure() is configured?
It is entirely up to the user who implements it, and it depends on the
algorithm he chose. If the algorithm does have some setXxx() setter, he
could do:
public DifferentiableMultivariateVectorialOptimizer
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
Le 26/11/2010 14:14, Gilles Sadowski a écrit :
Hello.
Should we simply allow user to register an instance of some optimizer
reconfigurator interface in the constructor ? Something like:
public MultiStartDifferentiableMultivariateVectorialOptimizer(
Hi,
Le 26/11/2010 14:23, Gilles Sadowski a écrit :
[...]
Question is how reconfigure() is configured?
It is entirely up to the user who implements it, and it depends on the
algorithm he chose. If the algorithm does have some setXxx() setter, he
could do:
public
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.e a root
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
are
On Mon, 22 Nov 2010 13:53:12 +0100, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
Hello.
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,
Le 22/11/2010 19:28, Nikolaus Hansen a écrit :
On Mon, 22 Nov 2010 13:53:12 +0100, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
Hello.
Hello,
There is something loosely similar to what you need in the ODE
packages.
This kind of algorithms also need some information to be provided
Hi.
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.
[...]
Does the this callback possibly
Hello,
Le 22/11/2010 22:16, Gilles Sadowski a écrit :
Hi.
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
Oh.
That is very different.
So why not have either
a) three getters to get the different matrices
or
b) one getter that returns a structure packaging these matrices?
Why use a callback structure?
in fact, it can and should serve both purposes: display the result of
finished runs and display the
Le 21/11/2010 19:12, Nikolaus Hansen a écrit :
Oh.
That is very different.
So why not have either
a) three getters to get the different matrices
or
b) one getter that returns a structure packaging these matrices?
Why use a callback structure?
in fact, it can and should serve both
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 not a
Oh.
That is very different.
So why not have either
a) three getters to get the different matrices
or
b) one getter that returns a structure packaging these matrices?
Why use a callback structure?
On Fri, Nov 19, 2010 at 1:55 AM, Dr. Dietmar Wolz drdietmarw...@yahoo.dewrote:
And it was not
Hi.
But seriously, the long running programs in Mahout are almost all map-reduce
jobs and there is a fairly good framework for
progress reporting in Hadoop. This includes normal logging as well as a
counter framework that allows code to drive status
counters in parallel out to a standard
On Fri, Nov 19, 2010 at 10:10 AM, Gilles Sadowski
gil...@harfang.homelinux.org wrote:
But seriously, the long running programs in Mahout are almost all
map-reduce
jobs and there is a fairly good framework for
progress reporting in Hadoop. This includes normal logging as well as a
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
Hello.
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.
[...]
The implementation is already ported to commons.math, it is mainly
dependent
on the linear package.
Did you use the
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 be passed as
Hello.
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?
Yes.
There were some changes introduced in the 3.0 development version.
Namely, please have a look at the BaseAbstractScalarOptimizer class
in
One thing that will make plotting possible is a project I'm working
on. Not ready for use, but here's a summary.
The amath4jtcl project provides an extension for the JTcl project
that allows one to use Commons Math Vectors and Matrices within Tcl
Expressions. In combination with my
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 meant
Hello.
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
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 not a
Mostly we complain that we don't have enough reporting just yet.
But seriously, the long running programs in Mahout are almost all map-reduce
jobs and there is a fairly good framework for
progress reporting in Hadoop. This includes normal logging as well as a
counter framework that allows code
30 matches
Mail list logo
