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