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 Differ
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(
>>> DifferentiableMul
>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
> > [...]
> > 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
> reconfigure(
Hello.
> >Should we simply allow user to register an instance of some optimizer
> reconfigurator interface in the constructor ? Something like:
> >
> > public MultiStartDifferentiableMultivariateVectorialOptimizer(
> > DifferentiableMultivariateVectorialOptimizer optimizer,
> > in
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(
>> DifferentiableMultivariateVectori
>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 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 popu
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
>> 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
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
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.
> >>> > [...]
> >>
> >>
Le 22/11/2010 19:28, Nikolaus Hansen a écrit :
> On Mon, 22 Nov 2010 13:53:12 +0100, Gilles Sadowski
> 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
>>> back t
On Mon, 22 Nov 2010 13:53:12 +0100, Gilles Sadowski
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, it is at the end of
each
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, it is at the end of each
> >integration step.
> > [...]
Does the this callback poss
>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
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 ser
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
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
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 stan
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 wrote:
> And it was not meant to monitor "pro
>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
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 to
On 11/18/10 7:17 PM, Ted Dunning wrote:
I really don't think that a general progress listener framework implies this
clutter and for long running algorithms is
a very nice thing.
I agree. Do you have specific ideas on how best to look at this?
What does Mahout do?
Phil
CM does not actual
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 goo
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 lo
>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
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 Swan
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 "BaseAbstractScalarOptimize
>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
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
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
33 matches
Mail list logo
